Symbol Table

【Symbol Table】

　　In order for GDB to be useful to us, it needs to be able to refer to variable and function names, not their addresses. Humans use names like main() or i. Computers use addresses like 0x804b64d or 0xbffff784. To that end, we can compile code with "debugging information" which tells GDB two things:

　　Because GCC and GDB run on so many different platforms, there are many different formats for debugging information:

• stabs: The format used by DBX on most BSD systems.
• coff: The format used by SDB on most System V systems before System V Release 4.
• xcoff: The format used by DBX on IBM RS/6000 systems.
• dwarf: The format used by SDB on most System V Release 4 systems.
• dwarf2: The format used by DBX on IRIX 6.
• vms: The format used by DEBUG on VMS systems.

　　If you plan on debugging an executable, a corefile resulting from an executable, or a running process, you mustcompile the executable with an enhanced symbol table. To generate an enhanced symbol table for an executable, we must compile it with gcc's -g option:

　　

　　As previously discussed, there are many different debugging formats. The actual meaning of -g is to produce debugging information in the native format for your system.

　　As an alternative to -g, you can also use gcc's -ggdb option:

　  

　　You can also give a numerical argument to -g, -ggdb and all the other debugging format options, with 1 being the least amount of information and 3 being the most. Without a numerical argument, the debug level defaults to 2. By using -g3 you can even access preprocessor macros, which is really nice. I suggest you always use -ggdb3 to produce an enhanced symbol table.

　　Debugging information compiled into an executable will not be read into memory unless GDB loads the executable.（程序运行时不会加载符号表，只GDB在调试程序时，GDB会去使用符号表）This means that executables with debug information will not run any slower than executables without debug information (a common misconception). While it's true that debugging executables take up more disk space, the executable will not have a larger "memory footprint" unless it's from within GDB. Similarly, executable load time will be nearly the same, again, unless you run the debug executable from within GDB.

　　One last comment. It's certainly possible to perform compiler optimizations on an executable which has an augmented symbol table, in other words: gcc -g -O9 try1.c. In fact, GDB is one of the few symbolic debuggers which will generally do quite well debugging optimized executables. However, you should generally turn off optimizations when debugging an executable because there are situations that will confuse GDB. Variables may get optimized out of existence, functions may get inlined, and more things may happen that may or may not confuse gdb. To be on the safe side, turn off optimization when you're debugging a program.

参考：http://rsquared.sdf.org/gdb/paefd.html