13

I'm aware of the debugging Rust questions here on StackOverflow and I also used gdb before with Go. However, I'm running into a problem where it seems gdb is unable to locate the debug symbols.

Consider this complex program in main.rs?

pub fn main () {
    println!("run");
}

I compile it with debug symbols

rustc -g main.rs

Then I run gdb

gdb main

This gives the first clue that something with the loading of debug symbols is not quite right.

enter image description here

Now when I'm in gdb and type

list

it leaves me with some C code which isn't what I expect.

enter image description here

What am I doing wrong? My gdb version is 7.7 and I'm on OS X 10.9.2 (13C64). My rustc version is rustc 0.11.0-pre (3035d8dfb13077e195eb056568183911c90c1b4b 2014-07-02 21:26:40 +0000)

It may also be helpful to see the output of `gdb --configuration``

$ gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin13.1.0 --target=x86_64-apple-darwin13.1.0
             --with-auto-load-dir=:${prefix}/share/auto-load
             --with-auto-load-safe-path=:${prefix}/share/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)
             --with-zlib
             --without-babeltrace
Christoph
  • 23,839
  • 25
  • 91
  • 129
  • Can’t reproduce on Arch Linux. – Chris Morgan Jul 09 '14 at 23:32
  • Which version or rust are you using? – Arjan Jul 10 '14 at 00:07
  • I'm on `rustc 0.11.0-pre (3035d8dfb13077e195eb056568183911c90c1b4b 2014-07-02 21:26:40 +0000)` – Christoph Jul 10 '14 at 08:54
  • Hm, this might be [#15567](https://github.com/rust-lang/rust/issues/15567); could you try the `-g -C llvm-args="-dwarf-version 4"` workaround suggested there? – huon Jul 10 '14 at 09:00
  • Nope, doesn't change anything for me. But what about */Users/cburgdorf/Documents/hacking/rust-playground/main.o* it seems it's trying to load symbols from `main.o` which does not exist? Or is it only trying to do that as a second attempt because it can't find them in the `main` binary? – Christoph Jul 10 '14 at 10:46
  • Are you using some customized .gdbinit file? In that if you have set some source code path, then this scenario may appear. – Mantosh Kumar Jul 10 '14 at 12:52
  • @MantoshKumar nope. I posted the output of `gdb --configuration`. Does this contain anything helpful? – Christoph Jul 10 '14 at 13:13
  • Ok, figured out what was wrong. See my own answer. Thank everyone for your help. I just wonder: As nobody pointed it out, is the `-g` parameter actually supposed to handle all that by itself? – Christoph Jul 10 '14 at 13:27

2 Answers2

13

Same question, later Rust version (1.0.0-beta), totally different answer:

In GDB, when debugging a Rust executable, break main sets a breakpoint in some setup code that is part of the Rust standard library. This isn't what you want.

Instead type: break $YOUR_CRATE::main, substituting the name of your program for $YOUR_CRATE.

Jason Orendorff
  • 39,955
  • 4
  • 59
  • 96
6

Ok, I figured out what was wrong. I have to manually emit the main.o file. I thought the -g parameter would just cut it.

Now that I run

rustc -g main.rs --emit="obj,link"

I can run

gdb main

And everything works like a charme.

I created two aliases for my bash to make things simple:

alias rd='rustc -g --emit="obj,link"'

compile_and_run() {
     rustc -g --emit="obj,link" $1 && gdb ${1%.*}
}

alias rdr=compile_and_run

Now I can just call rdr main.rs and it will start debugging main.rs with gdb.

Christoph
  • 23,839
  • 25
  • 91
  • 129