GDB 不显示 function 名称

Question

I am debugging from an embedded device using gdbserver:

./gdbserver HOST:5000 /home/test_app

In my PC, I execute gdb in this way:

arm-none-linux-gnueabi-gdb test_app

Once the application is executing, I receive the Segfault I want to debug, but it's impossible to know what line produced it:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 715]
0x31303030 in ?? ()
(gdb) bt
#0  0x31303030 in ?? ()
#1  0x0000dff8 in ?? ()
#2  0x0000dff8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(I must say I'm totally new to GDB)

Answer 1

Ok this usually happens if debug symbols are missing... just to make sure run following commands

file <your_executable>

you will get info on your binary like format, arch etc.. last part of the info describes if the binary is stripped or not. For debugging in GDB the binary should not have been stripped.

nm --debug-sym <your_executable> | grep debug

If you have some valid prints as below it means debug symbols are present.

00000000 N .debug_abbrev
00000000 N .debug_aranges
00000000 N .debug_frame
00000000 N .debug_info
00000000 N .debug_line
00000000 N .debug_loc
00000000 N .debug_pubnames
00000000 N .debug_str

Further when you invoke GDB you should have follwing line

Reading symbols from <your_executable>...done.

At this point you should be able to list sources with list command.

Make sure both gdb and gdbserver have same versioninig.

arm-none-linux-gnueabi-gdb --version
./gdbserver --version

If all the above are true, and you still don't get backtrace, there is something bad going on with your stack. Try running some static analysis, valgrind on your code / newly added code.

Answer 2

You need to build your application with debug symbols enabled. The switch for gcc is -g

Answer 3

For others, if nm --debug-sym <your_executable> | grep debug nm --debug-sym <your_executable> | grep debug prints the debug symbols but you do not get them in gdb, this might be because you are opening a core in gdb using a executable that is different from the one that generated the core.

Answer 4

You will need to include -g for every translation unit, for example, if you have a bunch of object files that are linked to build your final executable you will need to include -g for each compilation command.

g++ -g file1.cpp -c -o file1.o
g++ -g file2.cpp -c -o file2.o
...
g++ -g file1.o file2.o -o main