Next: Naming Conventions for GNAT Source Files, Previous: Remote Debugging using gdbserver, Up: Running and Debugging Ada Programs
When presented with programs that contain serious errors in syntax or semantics, GNAT may on rare occasions experience problems in operation, such as aborting with a segmentation fault or illegal memory access, raising an internal exception, terminating abnormally, or failing to terminate at all. In such cases, you can activate various features of GNAT that can help you pinpoint the construct in your program that is the likely source of the problem.
The following strategies are presented in increasing order of difficulty, corresponding to your experience in using GNAT and your familiarity with compiler internals.
The -gnatdO switch causes errors to be displayed as soon as they are encountered, rather than after compilation is terminated. If GNAT terminates prematurely or goes into an infinite loop, the last error message displayed may help to pinpoint the culprit.
gdb
directly on the gnat1
executable. gnat1
is the
front-end of GNAT, and can be run independently (normally it is just
called from gcc). You can use gdb
on gnat1
as you
would on a C program (but see The GNAT Debugger GDB for caveats). The
where
command is the first line of attack; the variable
lineno
(seen by print lineno
), used by the second phase of
gnat1
and by the gcc backend, indicates the source line at
which the execution stopped, and input_file name
indicates the name of
the source file.