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.

Click here to buy the book.

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

Share/Save/Bookmark




Verification Management
Join Verification Management Group


Shop Amazon - Contract Cell Phones & Service Plans

Book of the Month