58

GNU gdb Fedora (6.8-37.el5) Kernal 2.6.18-164.el5

I am trying to debug my application. However, everytime I pass the binary to the gdb it says:

(no debugging symbols found)

Here is the file output of the binary, and as you can see it is not stripped:

vid: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

I am compiling with the following CFLAGS:

CFLAGS = -Wall -Wextra -ggdb -O0 -Wunreachable-code

Can anyone tell me if I am missing some simple here?

A-Sharabiani
  • 17,750
  • 17
  • 113
  • 128
ant2009
  • 27,094
  • 154
  • 411
  • 609

10 Answers10

71

The most frequent cause of "no debugging symbols found" when -g is present is that there is some "stray" -s or -S argument somewhere on the link line.

From man ld:

   -s
   --strip-all
       Omit all symbol information from the output file.

   -S
   --strip-debug
       Omit debugger symbol information (but not all symbols) from the output file.
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 1
    Thanks, this helps me with debugging the Lua! Although I put the -g option in the makefile, there is also a -s option, which makes the gdb not able to find symbols. – Weixiang Guan Oct 31 '13 at 10:50
  • 4
    Another frequent cause of "no debugging symobls found" when -g is present is mispelling CFLAGS as CFLAGES. At least it was common for me today. – labyrinth Dec 21 '17 at 21:03
  • I'm trying to compile assembly with ld, and I removed the -s and added -g option but gdb still output no debugging symbols... – Silidrone Mar 31 '20 at 09:57
  • `install` from coreutils also has an `-s` option. I've bumped it in someone else's Makefile. – Chih-Hsuan Yen Dec 30 '20 at 16:24
  • You solved my problem! Thanks! +1 – UserX Oct 22 '21 at 21:37
54

The application has to be both compiled and linked with -g option. I.e. you need to put -g in both CPPFLAGS and LDFLAGS.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • 6
    Some operating systems do require -g at link time, but Linux is not one of them. Compiling with '-g' and linking without it still produces an executable with full debug info, so this answer is unlikely to be correct. – Employed Russian Mar 10 '11 at 23:24
  • 4
    @EmployedRussian You are right. However, I suggest avoiding doing non-portable shortcuts for no good reason. Documented behavior is maintained, undocumented - it is a risk you take. And I do not see any reward for the risk here. Adding `-g` to linker flags should cost you close to 0, yet it might save you a day. – Maxim Egorushkin Feb 14 '15 at 22:58
  • 2
    Would have never guessed it needed to be in LDFLAGS! – MrPickles Feb 25 '16 at 07:55
  • 1
    @EmployedRussian I'm on linux and adding it to the linker flags too fixed my issue. – Ludwik Jun 12 '18 at 13:17
  • 1
    Yeah, I was also able to solve the issue by adding -g flag while linking. Thanks @MaximEgorushkin – logdev Jun 08 '20 at 19:38
  • 1
    Thanks a lot! I spent ONE day resolving this issue. And I'm on Arch Linux, so it IS needed for some Linux system apparently. – ThePhi Nov 12 '20 at 16:02
  • @ThePhi Thank you, that's exactly what I meant by _might save you a day_ in my earlier comment. – Maxim Egorushkin Dec 02 '22 at 00:45
27

Some Linux distributions don't use the gdb style debugging symbols. (IIRC they prefer dwarf2.)

In general, gcc and gdb will be in sync as to what kind of debugging symbols they use, and forcing a particular style will just cause problems; unless you know that you need something else, use just -g.

geekosaur
  • 59,309
  • 11
  • 123
  • 114
  • 2
    Hello, I am made a mistake I was compiling with g++. However, I have changed to the -g debug option. However, it still fails to load symbols. Thanks. – ant2009 Mar 09 '11 at 10:50
  • Does `nm -a -C` on your program show debug symbols? How about `objdump -g -C`? Try replacing `-g` with -G` or `-W` in the latter. – geekosaur Mar 09 '11 at 11:20
  • 3
    There is no "gdb style" debugging symbols. GDB uses platform-standard debug format, which on Linux is dwarf{2,3,4}. – Employed Russian Mar 10 '11 at 23:25
  • 1
    For some reason I'm also having ton of problems with GDB and it not finding debugging symbols. nm -a -C libmylibrary.so outputs a large number of symbols, to which I'm not sure are debug or not. Linux file command outputs the the file is not-stripped. Where have all my debug symbols gone? All files were compiled with CFLAGS, CXXFLAGS and LDFLAGS that include -g. The strip-debug was taken out of the NDK build scripts as well. – Kevin Parker Aug 29 '11 at 19:35
6

You should also try -ggdb instead of -g if you're compiling for Android!

Kevin Parker
  • 16,975
  • 20
  • 76
  • 105
5

Replace -ggdb with -g and make sure you aren't stripping the binary with the strip command.

atx
  • 4,831
  • 3
  • 26
  • 40
3

I know this was answered a long time ago, but I've recently spent hours trying to solve a similar problem. The setup is local PC running Debian 8 using Eclipse CDT Neon.2, remote ARM7 board (Olimex) running Debian 7. Tool chain is Linaro 4.9 using gdbserver on the remote board and the Linaro GDB on the local PC. My issue was that the debug session would start and the program would execute, but breakpoints did not work and when manually paused "no source could be found" would result. My compile line options (Linaro gcc) included -ggdb -O0 as many have suggested but still the same problem. Ultimately I tried gdb proper on the remote board and it complained of no symbols. The curious thing was that 'file' reported debug not stripped on the target executable.

I ultimately solved the problem by adding -g to the linker options. I won't claim to fully understand why this helped, but I wanted to pass this on for others just in case it helps. In this case Linux did indeed need -g on the linker options.

Dave
  • 31
  • 1
  • I had a similar scenario - binaries built on one machine using a cross compilation toolchain, gdb on remote ARM board couldn't see symbols even though file said "not stripped" and nm showed the expected symbols. Rebuilt after adding "Wl,-g" and gdb on the remote board can now see the symbols. Thank you Dave! – Dan Groom Apr 10 '18 at 15:38
1

Hope the sytem you compiled on and the system you are debugging on have the same architecture. I ran into an issue where debugging symbols of 32 bit binary refused to load up on my 64 bit machine. Switching to a 32 bit system worked for me.

Shankara Narayana
  • 745
  • 9
  • 15
1

Bazel can strip binaries by default without warning, if that's your build manager. I had to add --strip=never to my bazel build command to get gdb to work, --compilation_mode=dbg may also work.

$ bazel build -s :mithral_wrapped
... 
#even with -s option, no '-s' was printed in gcc command
...
$ file bazel-bin/mithral_wrapped.so
../cpp/bazel-bin/mithral_wrapped.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=4528622fb089b579627507876ff14991179a1138, not stripped
$ objdump -h bazel-bin/mithral_wrapped.so  | grep debug

$ bazel build -s :mithral_wrapped --strip=never
...
$ file bazel-bin/mithral_wrapped.so
bazel-bin/mithral_wrapped.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=28bd192b145477c2a7d9b058f1e722a29e92a545, not stripped
$ objdump -h bazel-bin/mithral_wrapped.so  | grep debug
 30 .debug_info   002c8e0e  0000000000000000  0000000000000000  0006b11e  2**0
 31 .debug_abbrev 000030f6  0000000000000000  0000000000000000  00333f2c  2**0
 32 .debug_loc    0013cfc3  0000000000000000  0000000000000000  00337022  2**0
 33 .debug_aranges 00002950  0000000000000000  0000000000000000  00473fe5  2**0
 34 .debug_ranges 00011c80  0000000000000000  0000000000000000  00476935  2**0
 35 .debug_line   0001e523  0000000000000000  0000000000000000  004885b5  2**0
 36 .debug_str    0033dd10  0000000000000000  0000000000000000  004a6ad8  2**0
Clark Benham
  • 69
  • 1
  • 4
0

For those that came here with this question and who are using Qt: in the release config there is a step where the binary is stripped as part of doing the make install. You can pass the configuration option CONFIG+=nostrip to tell it not to:

Instead of:

qmake <your options here, e.g. CONFIG=whatever>

you add CONFIG+=nostrip, so:

qmake <your options here, e.g. CONFIG=whatever> CONFIG+=nostrip
Martijn de Milliano
  • 3,908
  • 3
  • 36
  • 45
0

The solutions I've seen so far are good:

  1. must compile with the -g debugging flag to tell the compiler to generate debugging symbols
  2. make sure there is no stray -s in the compiler flags, which strips the output of all symbols.

Just adding on here, since the solution that worked for me wasn't listed anywhere. The order of the compiler flags matters. I was including multiple header files from many locations (-I/usr/local/include -Iutil -I. And I was compiling with all warnings on (-Wall).

The correct recipe for me was:

gcc -I/usr/local/include -Iutil -I -Wall -g -c main.c -o main.o

Notice:

  • include flags are at the beginning
  • -Wall is after include flags and before -g
  • -g is at the end

Any other ordering of the flags would cause no debug symbols to be generated.

I'm using gcc version 11.3.0 on Ubuntu 22.04 on WSL2.

Yong Da Li
  • 1
  • 1