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.
gccwith the -gnatf. This first switch causes all errors on a given line to be reported. In its absence, only the first error on a line is displayed.
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.
-v (verbose)switch. In this mode,
gccproduces ongoing information about the progress of the compilation and provides the name of each procedure as code is generated. This switch allows you to find which Ada procedure was being compiled when it encountered a code generation problem.
gccwith the -gnatdc switch. This is a GNAT specific switch that does for the front-end what
-vdoes for the back end. The system prints the name of each unit, either a compilation unit or nested unit, as it is being analyzed.
gdbdirectly on the
gnat1is the front-end of GNAT, and can be run independently (normally it is just called from
gcc). You can use
gnat1as you would on a C program (but see The GNAT Debugger GDB for caveats). The
wherecommand is the first line of attack; the variable
print lineno), used by the second phase of
gnat1and by the
gccbackend, indicates the source line at which the execution stopped, and
input_file nameindicates the name of the source file.