| www.delorie.com/djgpp/v2faq/faq103.html | search |
| www.delorie.com/djgpp/v2faq/faq103.html | search |
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...
symify can identify; programs using alarm or setitimer can't be debugged, either. You can't hook the keyboard interrupt in a
debugged program, and you can'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 is that any exceptions or signals that happen when your program runs under a debugger will be caught by the debugger instead, and they
won't get passed to the debuggee. To debug programs which hook hardware interrupts, you will have to chain the old real-mode interrupt handler to your new handler, which requires to write special
debug version of the program. At least some of these limitations will be fixed in future versions of DJGPP. In case you need a Ctrl-<C> key-press to go to the debuggee instead of the debugger, a work-around is available: use the Alt-Numeric-3 (that is, press the <Alt> key, the press and release the <3> key on the numeric keypad. Some programs (but not Emacs) will also treat the Ctrl-<2> key-press as Ctrl-<C>.
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 uses the ordinary breakpoints to implement the step, next and similar commands, so you can't use these on Windows 3.X; use the 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 breakpoints and watchpoints cannot exceed 4). Same considerations apply to the debugger built into RHIDE under Windows 3.X.
| webmaster donations bookstore | delorie software privacy |
| Copyright ⌐ 1998 by Eli Zaretskii | Updated Sep 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)