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
compiling with -g. To use stabs debugging, compile with
-gstabs3 or -gstabs+ instead of -g. (Stabs
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
with the -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
GDB debugger):
gdb myprog.exe
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
so:
gdb myprog
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 GDB on Unix should know about the following important
differences in its operation on MS-DOS:
set args or run
commands), not from the GDB command line. Redirection of
standard input and standard output as part of the command line is
supported only in ports of GDB v4.18 and later.
GDB doesn'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.).
gdb.ini instead
of .gdbinit, because MS-DOS doesn't allow file names with leading
dots.
GDB uses the GNU readline package for its input. The
readline init file (~/.inputrc on Unix) is called
~/_inputrc on MS-DOS and should be in the directory pointed to by
the HOME environment variable.
FSDB, the full-screen debugger, from the djdev
distribution. 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 FSDB is 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 FSDB is 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 FSDB
understand them.
EDEBUG32 is 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
the debugger).