debugging - 如何使用 GDB 或 LLDB 等调试器在 Rust 中调试 crate？

Question

我正在写一个新的箱子。我为它编写了一些测试并使用 cargo test 运行测试。之后，在target文件夹中生成了一些test_xxx可执行文件。我在 Cargo.toml 中启用了调试选项。通过运行 gdb targets/test_xxx，我可以列出并调试 test_xxx 可执行文件中的代码。但是，我无法进入 crate 中的功能。没有调试信息。我如何构建/链接 crate 以包含其调试信息？

Answer 1

你的问题有点模糊，所以我会描述我做了什么:

创建一个新的箱子:

cargo new --lib so
cd so/

添加一小段代码:

src/lib.rs

fn thing1(a: i32) -> i32 {
    a + 2
}

fn thing2(a: i32) -> i32 {
    a * a
}

pub fn do_a_thing(a: i32, b: i32) -> i32 {
    thing2(b) - thing1(a)
}

创建了一个外部测试；一个在测试中的。这与您对 test_XXX 的评论相符，据我所知:

tests/alpha.rs

#[test]
fn it_works() {
    assert_eq!(1, so::do_a_thing(1, 2))
}

运行测试(输出修剪):

% cargo test

     Running target/debug/deps/alpha-b839f50a40d747a9

running 1 test
test it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

在我的调试器中打开它:

% lldb target/debug/alpha-b839f50a40d747a9

在 crate 中的方法上设置一个正则表达式断点并运行它:

(lldb) br set -r 'do_a_thing'
Breakpoint 1: where = alpha-b839f50a40d747a9`so::do_a_thing::hd55d34fb5a87e372 + 14 at lib.rs:10:11, address = 0x0000000100001f9e
(lldb) r
Process 53895 launched: '/tmp/so/target/debug/alpha-b839f50a40d747a9' (x86_64)

running 1 test
Process 53895 stopped
* thread #2, name = 'it_works', stop reason = breakpoint 1.1
    frame #0: 0x0000000100001f9e alpha-b839f50a40d747a9`so::do_a_thing::hd55d34fb5a87e372(a=1, b=2) at lib.rs:10:11
   7    }
   8
   9    pub fn do_a_thing(a: i32, b: i32) -> i32 {
-> 10       thing2(b) - thing1(a)
   11   }
Target 0: (alpha-b839f50a40d747a9) stopped.
(lldb) p b
(int) $0 = 2
(lldb) p a
(int) $1 = 1
(lldb) br set -r 'thing2'
Breakpoint 2: where = alpha-b839f50a40d747a9`so::thing2::hf3cb71248518a556 + 11 at lib.rs:6:4, address = 0x0000000100001f5b
(lldb) c
Process 53895 resuming
Process 53895 stopped
* thread #2, name = 'it_works', stop reason = breakpoint 2.1
    frame #0: 0x0000000100001f5b alpha-b839f50a40d747a9`so::thing2::hf3cb71248518a556(a=2) at lib.rs:6:4
   3    }
   4
   5    fn thing2(a: i32) -> i32 {
-> 6        a * a
   7    }
   8
   9    pub fn do_a_thing(a: i32, b: i32) -> i32 {
Target 0: (alpha-b839f50a40d747a9) stopped.
(lldb) p a
(int) $2 = 2

这表明我能够在我的 crate 中设置断点和调试。

对于依赖包

我将其添加到我的 Cargo.toml 中:

[dependencies]
time = "0.1.0"

连同此代码:

src/lib.rs

pub fn do_another_thing() -> bool {
    time::precise_time_ns() % 2 == 0
}

而这个测试(仍然在外部测试文件中):

tests/alpha.rs

#[test]
fn it_works2() {
    assert_eq!(true, so::do_another_thing())
}

像以前一样构建并运行测试，然后像以前一样在调试器中打开它:

(lldb) br set -r 'precise_time'
Breakpoint 1: where = alpha-25aace4e290c57ee`time::precise_time_ns::h21114d10b3e2c8e8 + 8 at lib.rs:161:4, address = 0x0000000100002278
(lldb) r
Process 54043 launched: '/tmp/so/target/debug/alpha-25aace4e290c57ee' (x86_64)

running 2 tests
test it_works ... Process 54043 stopped
* thread #2, name = 'it_works2', stop reason = breakpoint 1.1
    frame #0: 0x0000000100002278 alpha-25aace4e290c57ee`time::precise_time_ns::h21114d10b3e2c8e8 at lib.rs:161:4
   158   */
   159  #[inline]
   160  pub fn precise_time_ns() -> u64 {
-> 161      sys::get_precise_ns()
   162  }
   163
   164

为什么要使用正则表达式断点？

函数名称被破坏和命名空间。我们的函数实际上称为 so::do_a_thing::hd55d34fb5a87e372 或 time::precise_time_ns::h21114d10b3e2c8e8。使用正则表达式断点可以轻松选择这些断点，而无需考虑确切的名称。

你也可以使用LLDB的自动补全

(lldb) b so::<TAB>
Available completions:
    so::do_a_thing::hfb57d28ba1650245
    so::do_another_thing::hace29914503d7a2f
    so::thing1::ha6f7818d54de28d4
    so::thing2::h2518577906df58fd

(lldb) b time::<TAB>
Available completions:
    time::precise_time_ns::h21114d10b3e2c8e8
    time::sys::inner::mac::get_precise_ns::h64c88ed88da4ac18
    time::sys::inner::mac::info::_$u7b$$u7b$closure$u7d$$u7d$::ha03be28d018f231b
    time::sys::inner::mac::info::h364c1a0ef2ef1f0c

使用 GDB 代替 LLDB

您也可以使用 GDB，但看起来可能有点难。在 primary crate 的代码中设置断点后，我介入并看到函数名称似乎是损坏的版本。不过，您可以将其用作断点。

请注意我的正则表达式断点没有按预期工作，还要注意实际断点的行号:

(gdb) rbreak precise_time_ns
u64 _ZN4time15precise_time_nsE()();
static u64 _ZN4time15precise_time_ns18os_precise_time_nsE()();
Breakpoint 1 ('_ZN4time15precise_time_ns18os_precise_time_ns13closure.24322E') pending.
<function, no debug info> time::precise_time_ns::os_precise_time_ns::closure.24322;

(gdb) b _ZN4time15precise_time_nsE
Breakpoint 2 at 0x1000052a0: file lib.rs, line 172.

(gdb) r
Starting program: /private/tmp/so/target/alpha-e0c6f11f426d14d2

running 2 tests
test it_works ... ok
[Switching to process 49131 thread 0xd03]

Breakpoint 1, _ZN4time15precise_time_nsE () at lib.rs:172
172 pub fn precise_time_ns() -> u64 {
(gdb) list
167
168 /**
169  * Returns the current value of a high-resolution performance counter
170  * in nanoseconds since an unspecified epoch.
171  */
172 pub fn precise_time_ns() -> u64 {
173     return os_precise_time_ns();
174
175     #[cfg(windows)]
176     fn os_precise_time_ns() -> u64 {

调试器包装器

Rust 附带了两个包装程序:rust-lldb 和 rust-gdb。这些旨在增加每个调试器的实用性。值得给他们一个机会。