使用调试器
免责声明：这不是关于配置 Zed 调试器的文档。相反，它旨在向 Zed 员工和外部贡献者提供有关如何在开发 Zed 本身时使用调试器的信息。
使用 Zed 内置调试器
当 Zed 项目打开时，您可以打开新建进程模态框并选择调试选项卡。在那里您可以看到两个调试配置用于调试 Zed，一个用于 GDB，一个用于 LLDB。选择您想要的配置，Zed 将构建并启动二进制文件。
请注意，GDB 不支持 ARM MacBooks
发布构建配置文件注意事项
默认情况下，使用发布配置文件（发布是用于生产构建的配置文件，即每夜、预览和稳定版本）的构建包含有限的调试信息。
这是通过将根Cargo.toml文件中的profile.(release).debug字段设置为"limited"来完成的。
有关debug字段的官方文档可以在此处找到。但总而言之，"limited"会剥离类型和变量级别的调试信息。
在发布构建中，这样做是为了减小二进制文件的大小，因为不需要类型和变量级别的调试信息，并且不会影响生成的堆栈跟踪的可用性。
然而，虽然类型和变量级别的调试信息对于良好的堆栈跟踪不是必需的，但对于使用调试器来说非常重要，因为如果没有类型和变量级别的调试信息，调试器无法解析局部变量，检查它们，使用美化打印器格式化它们等。
因此，为了在调试发布版本时充分使用调试器，您必须编译一个新的 Zed 二进制文件，并包含完整的调试信息。
最简单的方法是在运行cargo run或cargo build时使用--config标志来覆盖根Cargo.toml文件中的debug字段，如下所示
cargo run --config 'profile.release.debug="full"'
cargo build --config 'profile.release.debug="full"'
如果您希望避免在每次调用
cargo时都传递--config标志。您也可以更改根Cargo.toml中的部分从
[profile.release] debug = "limited"到
[profile.release] debug = "full"这将确保所有
cargo run --release或cargo build --release的调用都将使用完整的调试信息进行编译。警告：请确保避免提交这些更改！
使用 shell 调试器 GDB/LLDB 运行 Zed
背景
通过 rustup 安装 rust 时（开发 Zed 时的推荐方式，请参阅此处的平台入门文档），会安装一些额外的脚本并将其放置在您的路径中，以协助调试用 rust 编译的二进制文件。
它们分别是rust-gdb和rust-lldb。
如果您有兴趣，可以在此处阅读更多关于这些脚本及其有用性的信息。
然而，总而言之，它们是简单的 shell 脚本，封装了标准的gdb和lldb命令，注入了相关命令和标志，以启用额外的 Rust 特定功能，例如美化打印器和类型信息。
因此，为了使用rust-gdb或rust-lldb，您的系统上必须安装gdb或lldb。如果未安装，您需要以适合您平台的方式安装它们。
根据之前链接的文章，“支持的最低调试器版本是 GDB 7.7 和 LLDB 310。然而，通用规则是：越新越好。”因此，建议尽可能安装最新版本的gdb或lldb。
注意：
rust-gdb在 Windows 上默认不安裝，因为gdb对 Windows 的支持不是很稳定。建议在 Windows 上使用lldb与rust-lldb。
如果您不熟悉gdb或lldb，您可以在此处和此处分别了解更多信息。
与 Zed 一起使用
在遵循上述步骤，在编译 Zed 时包含完整的调试信息后，您可以在使用cargo build构建编译后的 Zed 二进制文件后，通过运行以下命令之一，在其上运行rust-gdb或rust-lldb
rust-gdb target/debug/zed
rust-lldb target/debug/zed
或者，您可以通过运行以下命令之一，连接到 Zed 的运行实例（例如使用cargo run启动的 Zed 实例）
rust-gdb -p <pid>
rust-lldb -p <pid>
其中<pid>是您要连接的 Zed 实例的进程 ID。
要获取正在运行的 Zed 实例的进程 ID，您可以使用您的系统进程管理工具，例如 Windows 上的任务管理器或 macOS 上的活动监视器。
或者，您可以在 macOS 和 Linux 上运行ps aux | grep zed命令，或者在 Windows 的 PowerShell 实例中运行Get-Process | Select-Object Id, ProcessName。
调试恐慌和崩溃
调试器是调试所有程序（包括 Zed）中恐慌和崩溃原因的绝佳工具。
默认情况下，当gdb或lldb连接的进程遇到异常（例如恐慌）时，调试器将自动在恐慌点停止，并允许您检查程序的状态。
最有可能的是，调试器停止的点将深入到 Rust 标准库的恐慌或异常处理代码中，因此您需要向上导航堆栈跟踪以找到恐慌的实际原因。
这可以使用lldb中的backtrace命令结合frame select命令来完成，gdb中也有类似的命令可用。
一旦程序停止，您将无法像在发生异常之前那样继续执行。但是，您可以跳到不同的堆栈帧，并检查每个帧中变量和表达式的值，这对于确定崩溃的根本原因非常有用。
您可以在此处找到有关调试 Zed 崩溃的更多信息。