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.
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.
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.