Previous Section: gdb - The Tool of the Trade
Next Section: Commonly Used gdb Commands
In order to make gdb understand what's going on inside your program,
you must do certain things while compiling your source code. This part describes
how you can make your program gdb-friendly.
If you look inside an executable program, it has two parts. First, there
is a part which contains the actual executable machine code. This part
is also known as text.
The other part contains information about the text which are used during
run-time. This part contains information such as what are the libraries to
be loaded dynamically, what is the format for text (elf,
a.out etc.). This part may also contain something called
symbol table. A symbol table contains
information about all the variables used in the program. By looking into
a symbol table, it is possible to tell, among many other things, what
are the places (files and line numbers) where a particular variable is used
or which line does what in a file.
Any debugger (including gdb) uses the symbol table to keep track of the activity
of a program.
But unfortunately, symbol table in a typical program takes as much space
as the actual text itself. For this reason, even though a compiler generates
it during the compilation phase, it is usually discarded at the end and is
not attached to the text.
You can ask the compiler to retain the symbol table by specifying "-g" option
of any ANSI compliant C compiler. For example,
% cc -g mypli.c -o mypli
will generate mypli with the symbol table. It is ready to be
debugged using gdb.
Previous Section: gdb - The Tool of the Trade
Next Section: Commonly Used gdb Commands
|