delorie.com is funded by banner ads.
  www.delorie.com/djgpp/v2faq/faq103.html   search  

| Previous | Up | Top |

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: There are currently a few limitations in debugging programs which use interrupts or exceptions. Programs compiled for profiling may crash under a debugger with SIGSEGV or a GPF, with no addresses that 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  

Powered by Apache!

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)