8.1.1 The GNAT Debugger GDB

GDB is a general purpose, platform-independent debugger that
can be used to debug mixed-language programs compiled with `gcc',
and in particular is capable of debugging Ada programs compiled with
GNAT. The latest versions of GDB are Ada-aware and can handle
complex Ada data structures.

See Debugging with GDB,
for full details on the usage of GDB, including a section on
its usage on programs. This manual should be consulted for full
details. The section that follows is a brief introduction to the
philosophy and use of GDB.

When GNAT programs are compiled, the compiler optionally writes debugging
information into the generated object file, including information on
line numbers, and on declared types and variables. This information is
separate from the generated code. It makes the object files considerably
larger, but it does not add to the size of the actual executable that
will be loaded into memory, and has no impact on run-time performance. The
generation of debug information is triggered by the use of the
-g switch in the `gcc' or `gnatmake' command
used to carry out the compilations. It is important to emphasize that
the use of these options does not change the generated code.

The debugging information is written in standard system formats that
are used by many tools, including debuggers and profilers. The format
of the information is typically designed to describe C types and
semantics, but GNAT implements a translation scheme which allows full
details about Ada types and variables to be encoded into these
standard C formats. Details of this encoding scheme may be found in
the file exp_dbug.ads in the GNAT source distribution. However, the
details of this encoding are, in general, of no interest to a user,
since GDB automatically performs the necessary decoding.

When a program is bound and linked, the debugging information is
collected from the object files, and stored in the executable image of
the program. Again, this process significantly increases the size of
the generated executable file, but it does not increase the size of
the executable program itself. Furthermore, if this program is run in
the normal manner, it runs exactly as if the debug information were
not present, and takes no more actual memory.

However, if the program is run under control of GDB, the
debugger is activated. The image of the program is loaded, at which
point it is ready to run. If a run command is given, then the program
will run exactly as it would have if GDB were not present. This
is a crucial part of the GDB design philosophy. GDB is
entirely non-intrusive until a breakpoint is encountered. If no
breakpoint is ever hit, the program will run exactly as it would if no
debugger were present. When a breakpoint is hit, GDB accesses
the debugging information and can respond to user commands to inspect
variables, and more generally to report on the state of execution.