【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:
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
原文：http://www.cnblogs.com/tekkaman/p/3548694.html