14

I'm aware of the debugging Rust questions here on Stack Overflow 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.

GDB: can't open to read error

Now when I'm in GDB and type

list

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

screenshot of gdb list showing C code

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:

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
Matthias Braun
  • 32,039
  • 22
  • 142
  • 171
Christoph
  • 26,519
  • 28
  • 95
  • 133
  • 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
  • 42,793
  • 6
  • 62
  • 96
7

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
  • 26,519
  • 28
  • 95
  • 133