The GNAT Debugger GDB (GNAT User’s Guide for Native Platforms)

#### 6.1.1 The GNAT Debugger GDB ¶

`GDB` is a general purpose, platform-independent debugger that you can use to debug mixed-language programs, including 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. That manual should be consulted for full details. The section that follows is a brief introduction to the philosophy and use of `GDB`.

When 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 is 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 you used to perform the compilations. It is important to emphasize that it’s a goal of GCC, and hence GNAT, that the use of this switch does not change the generated code.

The compiler writes the debugging information 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 most cases, 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 does not increase the size of the executable program in memory. 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 you give a run command, the program runs 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 runs 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.