Mail Archives: djgpp/1999/12/16/20:37:37
On Wed, 15 Dec 1999, Marp wrote:
> Doesn't the program receive a SIGTRAP signal? Maybe he could try installing
> a handler for that (using function signal()) which restores the keyboard
> handler when a breakpoint is reached.
No, the debugged program doesn't receive a SIGTRAP when it hits a
breakpoint. If it did, any program would simply die under a debugger
the first time it gets to a breakpoint, because the default handler
for SIGTRAP aborts the program (and most programs never bother to
catch SIGTRAP).
What happens in reality is tremendously complicated, but in a
nutshell, the DJGPP debugging support functions set things in such a
way that the debugging exception triggered when the debuggee hits a
breakpoint is intercepted *before* SIGTRAP is generated. (Recall that
signals in DJGPP are generated by special code in response to
exceptions.) The debugger then examines the CPU registers and flags
at the point where the exception happened, and decides whether this is
due to a breakpoint or to something the program itself did (e.g., a
bug ;-). If the exception is due to a breakpoint, control is passed
to the debugger's application code (which lets you examine variables
etc.); if not, the thread needs to longjmp back into the debuggee's
code, so that the debuggee's code continues as if it were running
stand-alone.
Take a look at all the insanity that goes on in the dbgcom.c module
(and it gets much more insane in v2.03, to solve several grave
problems), if you really want to know the gory details.
In addition, the debuggee doesn't have any way of knowing what is the
keyboard handler of the debugger, so it cannot possibly restore it
when it hits a breakpoint. This must be done by the debugger, which
is how it works in the version of debugging support routines that will
be distributed with DJGPP v2.03.
- Raw text -