[an error occurred while processing this directive]
Node:How to debug,
Q: How do I debug my programs?
A: First, remember to use the
-g switch when you compile and
link. This puts debugging information into your executable. When
linking, don't use the
-s switch. Here are a few examples of
compilation and link command lines when you intend to debug a program:
gcc -Wall -c -g -O myfile.c gcc -Wall -O2 -g -o myprog.exe mymain.c mysub1.c mysub2.c -lm gcc -g -o myprog myprog.o mysub.o
Note that with
gcc, you can use optimization switches when
-g. To use stabs debugging, compile with
-gstabs+ instead of
debugging info is more powerful than the default COFF debugging; if the
debugger doesn't seem to support some feature, or behaves strangely, try
compiling the program with
-gstabs+ and see if that helps.)
Stabs debugging is especially recommended for C++ programs, since
the default format of debugging info is not powerful enough to record
all the necessary information about C++ code.
If (or when) GCC supports the dwarf2 debugging info, compile the program
-gdwarf2, since it is even better than stabs,
especially with the new generation of GCC optimizations.
Then, to debug the program, use a command line like this (here for the
Beginning with v2.01, DJGPP debuggers can debug both unstubbed COFF
images and DOS-style
.exe executables (v2.0 only supported COFF
files). To debug a COFF file, name it without the .exe extension, like
You can use one of several available debuggers with DJGPP:
GDB, the GNU Debugger. This is an extremely powerful source-level debugger, but it uses a line-oriented user interface. People who are familiar with using
GDBon Unix should know about the following important differences in its operation on MS-DOS:
runcommands), not from the
GDBcommand line. Redirection of standard input and standard output as part of the command line is supported only in ports of
GDBv4.18 and later.
GDBdoesn't know about PC-specific keys, so you cannot use the arrow keys for command history editing. Use ASCII control keys instead (^F for forward character, ^B for backward character, ^P for previous line, ^N for next line, etc.).
.gdbinit, because MS-DOS doesn't allow file names with leading dots.
GDBuses the GNU
readlinepackage for its input. The
readlineinit file (
~/.inputrcon Unix) is called
~/_inputrcon MS-DOS and should be in the directory pointed to by the
FSDB, the full-screen debugger, from the
djdevdistribution. This presents a user interface like that of Borland's Turbo Debugger, but unlike TD, it isn't a source-level debugger (although it will show the source code together with the machine instructions). It also supports data-write breakpoints: a powerful feature for hunting down code which overwrites data it shouldn't touch. Another advantage of
FSDBis that you can easily debug programs that grab the screen, because it can switch between the debugger screen and the application screen. Also, it allows to examine the FPU registers. The main disadvantage of
FSDBis that you cannot easily examine the contents of complex data structures. Remember to prepend an underscore
_to the names of C identifiers when you use them with
FSDB; for C++ programs you will have to find out the mangled names of static class variables and methods to make
EDEBUG32is the most basic debugger you can use with DJGPP.
You invoke any debugger like this:
<debugger-name> <program> <args...>
(except that with
GDB, you need to pass the arguments from within