16

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)

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
funkadelic
  • 311
  • 1
  • 2
  • 10
  • 1
    What flags did you compile with? Does GDB know where to get your source files from so it can display the line that it's stopped on? – Max Lybbert Dec 05 '11 at 19:47
  • 1
    I don't understand. Your PC is ARM? And you don't appear to be connecting to the GDB server at all. – Lightness Races in Orbit Dec 05 '11 at 19:56
  • 1
    Could you please post your compiler execution line and your full GDB commands? I concur with Tomalak Geret'kal that there is definitely something missing here, at least the connect to the GDB server and the command for setting the source directory. – thiton Dec 05 '11 at 20:28

4 Answers4

18

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.

Kamath
  • 4,461
  • 5
  • 33
  • 60
  • I do not think this answer is true. I have found several stripped files with visible function names (but no source is reproducable) – phil294 Jul 19 '17 at 06:40
5

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

pmr
  • 58,701
  • 10
  • 113
  • 156
  • Which is definitely one aspect, but there is more to cross-debugging with gdbserver. The OP didn't yet post enough information to answer the question. – thiton Dec 05 '11 at 20:27
  • I can't post now the full compilation options I used... but I used -g. – funkadelic Dec 06 '11 at 17:08
1

For others, if 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.

chreniuc
  • 23
  • 4
0

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
jackw11111
  • 1,457
  • 1
  • 17
  • 34