Including debug symbols when compiling rustc


#1

Hi! I’ve been trying to run the Rust compiler through GDB, and I’ve been having an issue where it seems to only detect symbols present in the src/rustc/rustc.rs file, and not all of the child libraries where the code actually is. As an example, this is what I get when I run the info functions command in gdb:

All defined functions:

File src/rustc/rustc.rs:
static fn rustc::main();

Non-debugging symbols:
0x00000000000006d0  _init
0x0000000000000700  std::rt::lang_start@plt
0x0000000000000710  rustc_driver::main@plt
0x0000000000000720  __libc_start_main@plt
0x0000000000000740  _start
0x0000000000000770  deregister_tm_clones
0x00000000000007b0  register_tm_clones
0x0000000000000800  __do_global_dtors_aux
0x0000000000000840  frame_dummy
0x0000000000000880  main
0x00000000000008b0  __libc_csu_init
0x0000000000000920  __libc_csu_fini
0x0000000000000924  _fini

I’ve enabled debuginfo = true in the config.toml file which got those symbols there in the first place, but I haven’t been having any luck with getting all of the other symbols in. Is there something I need to do to GDB to get it to read those symbols, or is something going on during compilation? I’m compiling rustc through WSL on Windows 10, if that has anything to do with it.


#2

It may be because of your gdb version, I know it only gained support for Rust in version 7.1.2. I’m on Arch Linux with gdb 8.0 and can see the symbols fine.

$ rustc --version
rustc 1.20.0-nightly (37849a002 2017-06-30)
$ gdb --version
GNU gdb (GDB) 8.0

Another (probably more powerful) way is to use nm to inspect binaries. nm is a program for inspecting the symbols in a binary and is part of the GNU binutils, so you probably already have it installed.

$ cd /tmp
$ cargo new --bin tester
$ cargo build --release
$ nm -gC target/release/tester   
0000000000256360 V DW.ref.rust_eh_personality
                 U _Unwind_Backtrace@@GCC_3.3
...
0000000000039d60 T <std_unicode::lossy::Utf8LossyChunksIter<'a> as core::iter::iterator::Iterator>::next
0000000000039d50 T std_unicode::lossy::Utf8Lossy::from_bytes
0000000000039d30 T std_unicode::tables::general_category::N
...
0000000000006df0 T main
000000000001f040 T mallctl
000000000001c650 T malloc

Note: the “-C” demangles symbols and “-g” only shows external symbols.

You can see that even in release mode cargo will leave loads of symbols around for a tiny “Hello World” program.

Are you trying to debug a #[no_std] program by any chance? I copied a no_std example from The Book and got something almost identical to you.

$ cargo build --release
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000201020 D __TMC_END__
0000000000201020 B __bss_start
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000201018 D __dso_handle
                 w __gmon_start__
0000000000000680 T __libc_csu_fini
0000000000000610 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.2.5
0000000000201020 D _edata
0000000000201028 B _end
0000000000000684 T _fini
00000000000004b8 T _init
00000000000004f0 T _start
0000000000000600 T main

If so, the reason you aren’t seeing many symbols is simply because they don’t exist. An empty #[no_std] binary is about the smallest binary you’ll get in Rust… without any funny business, anyway.


#3

I’m running GDB 8.0, and I’m debugging the rust compiler which should have quite a few more symbols. However, it doesn’t look like GDB was loading the .so files rustc depends on, and was only looking in the rustc binary itself! Once I ran the compiler once through GDB, it loaded up the shared libraries and found the symbols it needed.