[an error occurred while processing this directive] Node:Debugging woes, Previous:Complex vars, Up:Debugging

12.10 Debuggers choke on some programs ...

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.

[an error occurred while processing this directive]