[an error occurred while processing this directive] Node:How to debug, Next:, Previous:Debugging, Up:Debugging

12.1 How to run a DJGPP program under debugger

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:

  1. RHIDE, the DJGPP IDE by Robert Hoehne which 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.
  2. 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:
  3. 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.
  4. 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).

[an error occurred while processing this directive]