How to debug a crate in rust

I am writing a new crate. I wrote some tests for it and run the tests using cargo test. After that, some test_xxx executables are generated in target folder. I have enabled the debug option in Cargo.toml. By running gdb targets/test_xxx, I can list and debug the code in test_xxx file. However, I could not step into the functions in the crate. There is no debug information. How can build/link the crate to include its debug information?

Follow up

I did more reasearch and found my original question is inaccurate. It doesn't happen to all methods in an external crate, but only those generic ones. I filed an issue with the detail steps: https://github.com/rust-lang/rust/issues/19228. Please read comments there.

This is what I am doing to debug the generic method:

Write the tests in the tests folder as usual. Run "cargo test" to check if it is successful.
If it is failed, I move the test code into the crate lib.rs file and build a binary using "rustc -g src/lib.rs".
Using gdb to debug lib.

Your question is a bit fuzzy, so I'll describe what I did:

Create a new crate:

cargo new so
cd so/

Add a small bit of code:

// src/lib.rs

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

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

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

Created an external test; one that lives in tests. This matches your comment about test_XXX, as best I can guess:

// tests/alpha.rs

extern crate so;

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

Run the tests:

$ cargo test
     Running target/alpha-e0c6f11f426d14d2

running 1 test
test it_works ... ok

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

Open it up in my debugger:

$ lldb target/alpha-e0c6f11f426d14d2

Set a breakpoint on methods in the crate and run it:

(lldb) br set -r 'do_a_thing'
Breakpoint 1: where = alpha-e0c6f11f426d14d2`so::do_a_thing + 53 at lib.rs:10, address = 0x00000001000629f5
(lldb) r
Process 16843 launched: '/private/tmp/so/target/alpha-e0c6f11f426d14d2' (x86_64)

running 1 test
Process 16843 stopped
* thread #2: tid = 0x774ee, 0x00000001000629f5 alpha-e0c6f11f426d14d2`so::do_a_thing(a=1, b=2) + 53 at lib.rs:10, stop reason = breakpoint 1.1
    frame #0: 0x00000001000629f5 alpha-e0c6f11f426d14d2`so::do_a_thing(a=1, b=2) + 53 at lib.rs:10
   7    }
   8
   9    pub fn do_a_thing(a: int, b: int) -> int {
-> 10       thing2(b) - thing1(a)
   11   }
(lldb) p b
(long) $0 = 2
(lldb) p a
(long) $1 = 1
(lldb) br set -r 'thing2'
Breakpoint 2: where = alpha-e0c6f11f426d14d2`so::thing2 + 46 at lib.rs:6, address = 0x00000001000629ae
(lldb) c
Process 16843 resuming
Process 16843 stopped
* thread #2: tid = 0x774ee, 0x00000001000629ae alpha-e0c6f11f426d14d2`so::thing2(a=2) + 46 at lib.rs:6, stop reason = breakpoint 2.1
    frame #0: 0x00000001000629ae alpha-e0c6f11f426d14d2`so::thing2(a=2) + 46 at lib.rs:6
   3    }
   4
   5    fn thing2(a: int) -> int {
-> 6        a * a
   7    }
   8
   9    pub fn do_a_thing(a: int, b: int) -> int {
(lldb) p a
(long) $2 = 2

This indicates that I was able to set breakpoints and debug in my crate.

EDIT For the followup comment about dependent crates:

I added this to my Cargo.toml:

[dependencies]

time = "~0.1.0"

Along with this code:

// src/lib.rs

extern crate time;

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

And this test (still in the external test file):

// tests/alpha.rs

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

Built and ran the tests as before, then opened it in the debugger as before:

(lldb) br set -r 'precise_time'
Breakpoint 1: 4 locations.
(lldb) r
Process 17279 launched: '/private/tmp/so/target/alpha-e0c6f11f426d14d2' (x86_64)

running 2 tests
test it_works ... ok
Process 17279 stopped
* thread #2: tid = 0x799a1, 0x00000001000052c9 alpha-e0c6f11f426d14d2`time::precise_time_ns + 41 at lib.rs:173, stop reason = breakpoint 1.2
    frame #0: 0x00000001000052c9 alpha-e0c6f11f426d14d2`time::precise_time_ns + 41 at lib.rs:173
   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 {

Using GDB instead of LLDB

You can also use GDB, but it looks like it may be a bit harder. After setting a breakpoint in the primary crate's code, I stepped in and saw the function name seem to be the mangled version. You can use that as a breakpoint though.

Note my regex breakpoint doesn't work as intended, and also note the line number of the real breakpoint:

(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 {