| Previous | Next | Up | Top |
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.
Then, to debug the program, use a command line like this (here for gdb):
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:
- RHIDE, the DJGPP IDE by Robert Hoehne is available from the DJGPP archives. It includes an
integrated source-level debugger based on GDB code and presents a user interface like that of Borland's IDE or Turbo Debugger.
- RHGDB, a stand-alone version of GDB with a Turbo Vision user interface. RHGDB is part of the RHIDE distribution; it only supports part of GDB features.
- 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.
- GDB, the GNU Debugger. This is a 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:
- The command-line arguments can be only passed to the debuggee(Note: That's the program being debugged, in case you didn't know.) from within the debugger (use the set
args or run commands), not from the GDB command line.
- GDB is currently configured for DJGPP in a way that makes loading a program and reading a source file when a breakpoint is hit exceedingly slow: it can take more
than a minute for a very large program. Be patient and don't decide that GDB is wedged unless you've waited several minutes. A source-level patch to GDB was posted to the DJGPP News
group, which corrects this problem; you can get this patch by searching the DJGPP mail archives.
- 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.).
- The debugger and the debuggee share their file handles. This means, for example, that if your program redirects or closes its
stdin or stdout, you will be unable to
communicate with GDB.
- The initial commands are read from a file named 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 root directory of the current drive.
- EDEBUG32 is the most basic debugger you can use with DJGPP. One case when you would need to use it is when you debug a DXE module (see explanation of what a DXE
is), because GDB doesn't support debugging DXEs.
You invoke any debugger like this:
<debugger-name> <program> <args...>
You can help support this site by
visiting the advertisers that sponsor it! (only once each, though)