Q: I cannot debug Emacs (or any program that requests raw keyboard
input): when I press Ctrl-C, any debugger I tried reported SIGINT. But
I cannot operate the debugged program without Ctrl-C (in Emacs, it's
necessary to exit the editor)!
Q: I cannot debug any program which catches signals!!??
Q: I compiled my program with -pg switch, and now I cannot
debug it....
Q: When my program hits a breakpoint in GDB, the debugger reports
SIGSEGV, but only under Windows....
A: Versions of DJGPP before v2.03 had a few grave limitations in
debugging programs which use interrupts or exceptions. Programs
compiled for profiling would crash under a debugger with SIGSEGV or a
GPF, with no addresses that symify can identify; programs using
alarm or setitimer couldn't be debugged, either. You
couldn't hook the keyboard interrupt in a debugged program, and you
couldn't debug a program which uses floating point on a machine without
FP hardware (unless you use WMEMU as your emulator, but even
WMEMU doesn't solve all the problems). The reason for all these
problems was that any exceptions or signals that happen when your
program runs under a debugger would be caught by the debugger instead,
they won't get passed to the debuggee, and would usually terminate the
debuggee.
This is no more the case. DJGPP v2.03 and later have a much better
debug support, so all of the problems mentioned above are gone. The
DJGPP port of GDB 4.18, released in August 1999, is based on the
debugging support from DJGPP v2.03 and thus doesn't have most of these
problems anymore. Latest versions of RHIDE also use this improved
debugging support, as do the versions of edebug32 and
fsdb from DJGPP v2.03 or later.
Some problems still remain, though, even in v2.03: if you use the stock
emu387.dxe FP emulator while debugging floating-point programs or
debug programs that call alarm or setitimer library
functions, the program will sometimes crash with SIGSEGV. This
is likely to change in the future.
Beginning with version 1.1, the debugger built into RHIDE supports debugging programs that hook keyboard and/or timer hardware interrupts, so if you need e.g. to debug programs built with the Allegro library or programs compiled for profiling, you can use RHIDE.
Another known problem is that GDB GP Faults when the program hits a
breakpoint under Windows 3.X (Windows 9X doesn't have this problem).
This is because the breakpoint instruction causes a software interrupt
(as opposed to an exception) under Windows 3.X, and the DJGPP debug
support currently only catches debug exceptions. The only work-around
is to use the hardware breakpoints (which use the special debug
registers of the i386 and higher CPUs, and which do work with DJGPP on
Windows 3), and never have more than 4 of them active at the same time.
FSDB will automatically use the hardware breakpoints for the
first 4 breakpoints (so it works on Windows 3.X unless you set more than
4 breakpoints simultaneously), but with GDB, you will have to explicitly
use the hbreak and thbreak (instead of break and
tbreak) commands which set hardware breakpoints. This works with
DJGPP ports of GDB 4.16 and later. Note that GDB and FSDB use ordinary
breakpoints to implement single-stepping with the step,
next, <F7>, <F8> and similar commands, so you can't use
these on Windows 3.X; use temporary hardware breakpoints instead. The
above is also true for watchpoints (which watch for variables to change
value): you need to use hardware watchpoints with GDB (the total number
of hardware breakpoints and watchpoints cannot exceed 4). Same
considerations apply to the debugger built into RHIDE under Windows
3.X.