[Update]: This blog post has been updated to Rust 0.11 as of mid-April 2014. The previous version was for Rust 0.9.
This blog entry outlines the current state of my understanding of how to use the gdb debugger for Rust programs. As of this writing, I'm using:
$ rustc -v
rustc 0.11-pre-nightly (e332287 2014-04-16 00:56:30 -0700)
host: x86_64-unknown-linux-gnu
$ gdb --version
GNU gdb (GDB) 7.6.1-ubuntu
A caveat before we begin: I'm not an expert in gdb and I'm (now less of) a newbie at Rust. I'm cataloging my findings for both my own future reference and to help anyone who needs to see an example in action. I'd welcome feedback on tips for better ways to do this.
/* ---[ GDB ]--- */
I won't give a gdb tutorial. There are lots of good ones on the web, such as these:
- http://betterexplained.com/articles/debugging-with-gdb/
- http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
- http://beej.us/guide/bggdb
/* ---[ The setup ]--- */
The example I'll use is modified from an example from cmr in this Rust issue: https://github.com/mozilla/rust/issues/10350. I've chosen this one because it shows jumping into both a regular (named) function and an anonymous closure.
The codebase consists of two files, both in the same directory:
quux.rs:
pub fn quux00(x: || -> int) -> int {
println!("DEBUG 123");
x()
}
and bar.rs
extern crate quux;
fn main() {
let mut y = 2;
{
let x = || {
7 + y
};
let retval = quux::quux00(x);
println!("retval: {:?}", retval);
}
y = 5;
println!("y : {:?}", y);
}
To compile them with debugging info included use the -g switch (this changed since version 0.9):
$ rustc -g --crate-type lib quux.rs
$ rustc -g -L . bar.rs
Start the bar program in gdb and let's set some breakpoints:
$ gdb bar
(gdb) break bar::main
Breakpoint 1 at 0x4042c0: file bar.rs, line 3.
(gdb) rbreak quux00
Breakpoint 2 at 0x43e760: file quux.rs, line 1.
int quux::quux00(int ())(int ());
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004042c0 in bar::main at bar.rs:3
2 breakpoint keep y 0x000000000043e760 in quux::quux00 at quux.rs:1
For the first breakpoint, I know the full path, so I just use break.
Sometimes correct full paths in Rust can be tricky, especially for functions that are parametized, so it can be easier to just use rbreak, which takes a regular expression. All functions that match the regex will have a breakpoint set.
The second breakpoint does have the word "quux00" in it, but it's been mangled. There's a way to change that in Rust, but let's move on for the moment.
/* ---[ Aside: rbreak ]--- */
In my playing around so far, I've been unable to use break to set a breakpoint for a function not in the file with the main method, so rbreak has been very useful.
The rbreak command is pretty powerful. According to the documentation, if you want to set a breakpoint for all functions, rbreak . will do the trick. You don't want to do this for a rust application, because there are hundreds of functions that get compiled in.
Instead, you'll want to limit the scope of the regex search by limiting the search to a single file with:
(gdb) rbreak bar.rs:.
But again I've only gotten this to work for the "main" file. If I type rbreak quux.rs:. it doesn't know what I'm talking about. Something for future research.
/* ---[ Let's debug ]--- */
So now we've got two breakpoints set, as indicated by the output from info breakpoints.
Let's start the debugging session:
(gdb) run
Starting program: /home/midpeter444/lang/rust/sandbox/debug/./bar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
... deleted a bunch of info about threads starting up ...
Breakpoint 1, bar::main () at bar.rs:3
3 fn main() {
(gdb) n
4 let mut y = 2;
(gdb) n
9 let retval = quux::quux00(x);
(gdb) list
4 let mut y = 2;
5 {
6 let x = || {
7 7 + y
8 };
9 let retval = quux::quux00(x);
10 println!("retval: {:?}", retval);
11 }
12 y = 5;
13 println!("y : {:?}", y);
(gdb) p y
$1 = 2
(gdb) p x
$2 = {int ()} 0x7fffffffd4f8
Interesting that it seemed to skip lines 5-8 when I single stepped with n. But the x value was captured as an unnamed function, as you can see on the last line of the readout.
Now we are on line 8 (confirmed with the frame command below), so let's continue - our breakpoint on the quux00 function should now be tripped:
(gdb) frame
#0 bar::main () at bar.rs:9
9 let retval = quux::quux00(x);
(gdb) c
Continuing.
Breakpoint 2, quux::quux00 (x={int ()} 0x7fffffffd500) at quux.rs:1
1 pub fn quux00(x: || -> int) -> int {
Yes, it was tripped. Let's look around and single-step through it:
(gdb) frame
#0 quux::quux00 (x={int ()} 0x7fffffffd500) at quux.rs:1
1 pub fn quux00(x: || -> int) -> int {
(gdb) list
1 pub fn quux00(x: || -> int) -> int {
2 println!("DEBUG 123");
3 x()
4 }
(gdb) s
2 println!("DEBUG 123");
(gdb) p x
$4 = {int ()} 0x7fffffffd390
OK, we're inside the quux00 method. We stepped over the first instruction (the println) and inspected the x param, which is our anonymous Rust closure. Let's continue by stepping into the closure and see if that works:
(gdb) n
DEBUG 123
3 x()
(gdb) s
fn1356 () at bar.rs:6
6 let x = || {
(gdb) n
7 7 + y
(gdb) p y
$5 = 2
(gdb) n
bar::main () at bar.rs:10
10 println!("retval: {:?}", retval);
Excellent. That worked and we even had line numbers. Now we are back in the outer main fn. BTW, note that the "anonymous" closure has a name: fn1356 - remember that name, we'll come back to it later.
It's an easy walk to the finish line from here:
(gdb) list
5 {
6 let x = || {
7 7 + y
8 };
9 let retval = quux::quux00(x);
10 println!("retval: {:?}", retval);
11 }
12 y = 5;
13 println!("y : {:?}", y);
14 }
(gdb) p retval
$3 = 9
(gdb) n
2
(gdb) p y
$4 = 2
(gdb) c
Continuing.
retval: 9
y : 5
[Inferior 1 (process 7007) exited normally]
/* ---[ Round 2: Set breakpoints on all methods in main file ]--- */
Let's start over and set breakpoints on all the functions in the bar.rs file:
$ gdb bar
(gdb) rbreak bar.rs:.
Breakpoint 1 at 0x4042c0: file bar.rs, line 3.
static void bar::main();
Breakpoint 2 at 0x404520: file bar.rs, line 6.
static int fn1356()();
Aah, there's the name again: fn1356. So that's another way to set a breakpoint on your closures. If we redo the session, we'll see that the breakpoint now gets tripped in the closure as it's being executed (from within the quux00 method):
(gdb) r
Starting program: /home/midpeter444/lang/rust/sandbox/debug/bar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, bar::main () at bar.rs:3
warning: Source file is more recent than executable.
3 fn main() {
(gdb) c
Continuing.
DEBUG 123
Breakpoint 2, fn1356 () at bar.rs:6
6 let x = || {
(gdb) frame
#0 fn1356 () at bar.rs:6
6 let x = || {
(gdb) n
7 7 + y
(gdb) p y
$1 = 2
/* ---[ Round 3: Demangle function names ]--- */
In the Rust 0.9 version of this post I showed how rust mangled the function names, but that seems to have gone away. You can still explicitly specify not to mangle function names like so:
#[no_mangle]
pub fn quux00(x: || -> int) -> int {
println("DEBUG 123");
x()
}
I haven't tried anything really complicated with Rust in gdb yet, but hopefully these examples serve to get you going.
