19

When I tried to debug an executable:

(gdb) break +1
No symbol table is loaded.  Use the "file" command.

What does that mean exactly?

Is the symbol table appended to the executable?

Minh-Triet Pham Tran
  • 349
  • 4
  • 13
user198729
  • 61,774
  • 108
  • 250
  • 348

4 Answers4

33

There are two sets of symbols that gdb uses.

The -g set are debugging symbols, which make things a lot easier as they allow you to see your code and look at variables while debugging.

Another set of symbols is included by default when you compile. These are the linking symbols and live in the ELF (executable linkable format) symbol table. This contains a lot less info than the debug symbols, but contain the most important stuff, such as the addresses of the things in your executable (or library or object file). Without this information gdb won't even know where main is, so (gdb) break main would fail.

If you don't have the debugging symbols ( -g ) then you will still be able to (gdb) break main but you gdb will not have any concept of the lines of code in your source file. When you try to step through the code you will only advance 1 machine instruction at a time, rather than a line at a time.

The strip command is often used to strip off symbols from an executable (or other object file). This is often used if you don't want someone to be able to see the symbols or if you want to save space in the file. Symbol tables can get big. Strip removes both the debug symbols and the linker symbols, but it has several command line switches which can limit what it removes.

If you run the file command on your program one of the things it will tell you is weather or not the executable is has been stripped.

$ gcc my_prog.c -o my_prog
$ file my_prog
my_prog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
$ strip my_prog
my_prog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
$
nategoose
  • 12,054
  • 27
  • 42
  • are you sure linker symbols (`.dynsym`, right?) are removed by `strip`? According to [this](http://stackoverflow.com/a/8624223/264047) they are not. – Alexander Malakhov Mar 13 '13 at 04:56
  • 2
    `strip` has options that control which symbols are and are not removed. The default behavior usually doesn't break things. – nategoose Mar 18 '13 at 21:31
  • @nategoose can you please tell us wether or not the debugging symbols inlcude the symbols in the ELF symbol table. IN other words, does GDB only use the debugging symbols when the application has been compiled with -g ? – Manuel Selva Jun 08 '15 at 12:47
  • 2
    @ManuelSelva The ELF format was generated in conjunction with the DWARF debugging symbol format, and unlike many older object file formats has built in support for debugging symbols. Older object file formats had debugging symbol facilities hacked on by misusing other facilities of the format. The `-g` flag means "debug symbols, please" to many compilers, but they can add symbols without it or not produce them with it. These symbols have information like "code address=>(function:line number)" and also "at this code address, the most up to date value for X is in this register". – nategoose Jun 09 '15 at 18:55
8

It's because you didn't compile with debugging turned on. Try gcc -g file.c

rkulla
  • 2,494
  • 1
  • 18
  • 16
  • Do you mean gdb can't be used to debug arbitary programe? – user198729 Apr 05 '10 at 05:40
  • 2
    @user198729: You can use GDB to debug an arbitrary program, but you have to work a lot harder if the program does not have a symbol table. Basically, the symbol table tells the debugger about the functions and variables and line numbers and source files - and if it is missing, all you've got left is assembler. – Jonathan Leffler Apr 05 '10 at 05:51
  • @Jonathan Leffler,it seems you mean it's still possible to debug the program even if it doesn't have a symbol table,can you give an example? – user198729 Apr 05 '10 at 05:56
  • 1
    I mean it is very tough - tough enough that I wouldn't bother to try. But there are those who work in assembler and can debug an arbitrary program. I think they're mad, but they're probably also better programmers than me - in some respects, at least. You end up stepping through the code one assembler instruction at a time. – Jonathan Leffler Apr 05 '10 at 06:33
4

The symbol table contains debugging information that tells a debugger what memory locations correspond to which symbols (like function names and variable names) in the original source code file. The symbol table is usually stored inside the executable, yes.

gdb is telling you that it can't find that table. If you compiled with gcc, unless you used the -g flag, it will not include the symbol table in the file. The easiest method is probably to recompile your file with -g. gdb should then automatically find the symbol table information.

Either add the -g flag to the command line arguments of gcc or to the Makefile that you used to compile the program. (A lot of times, there will be a variable called CFLAGS or similar inside the Makefile).

If you are trying to debug an arbitrary third-party program, a lot of times the information will have been "stripped" out of it. This is done to make reverse engineering harder and to make the size of the executable file smaller. Unless you have access to the source code and can compile the program yourself, you will have a very hard time using gdb on it.

RarrRarrRarr
  • 3,712
  • 1
  • 20
  • 14
  • Why some other tools like softice can debug arbitrary program,aren't they using the same techniques as gdb? – user198729 Apr 05 '10 at 05:54
  • Roughly the same techniques, yes. You can do similar things with gdb like put breakpoints on system calls or examine assembly code or look at register values or contents of specific memory addresses, even without a symbol table. You may also want to check out strace or ltrace if you are on Linux. – RarrRarrRarr Apr 05 '10 at 05:59
  • But no matter what command I type,gdb always responds with `No symbol table is loaded. Use the "file" command.`,it seems impossible for it to debug a program without symbol table..Or maybe there is something I'm missing out? – user198729 Apr 05 '10 at 06:07
  • 1
    @user198729: with no symbol table, you cannot do symbolic debugging. You have to include the correct compilation options when creating the object files and when linking - most often, that is '`-g`' for both object generation and linking. You must also not specify '`-s`' (strip), nor must you subject the program to '`strip`'. – Jonathan Leffler Apr 05 '10 at 06:55
  • 1
    @Jonathan Leffler ,can you contrive a helloworld demo to debug program without symbol table? – user198729 Apr 05 '10 at 07:00
3

Find the entry point of the application.

objdump -f main

    main:     file format elf32-i386
    architecture: i386, flags 0x00000112:
    EXEC_P, HAS_SYMS, D_PAGED
    start address 0x08048054

Put a breakpoint there using the gnu debugger

gdb

    exec-file main
    break *0x8048054
    set disassemble-next-line on
    run

Then step through the code

gdb

    stepi

Special Notes

If you are using the latest version of Ubuntu you would not be affected by this, but you may run into this bug if you are running Ubuntu 10.04 or older.

https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/151518G

The solution would be to start debugging at the entry point address plus one.

Elite Mx
  • 113
  • 7