Mail Archives: djgpp/1999/12/15/22:47:41
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.
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote in message
news:Pine DOT SUN DOT 3 DOT 91 DOT 991215090642 DOT 18491I-100000 AT is...
>
> On Tue, 14 Dec 1999, Gero Timann wrote:
>
> > I'm developing a program, which also reprogram the keyboard-controller.
> > My problem now, if during running the program under RHIDE a breakpoint
> > arrived, the keyboard environment isn't restored to default and the
> > debugger is useless -> the keyboard doesn't function. (Similar problems
> > appear, if i redirect the mouse-handler to my own handler)
>
> This is a known problem, see section 12.10 of the FAQ for more gotchas
> of this kind. Since the debugger and the debuggee are running in the
> same process, the DJGPP debug support needs a lot of trickery to
> create an illusion of two separate processes. For each shared
> resource, such as file handles, current working directory, interrupts,
> signals, exceptions, etc., the debug support functions need to save and
> restore state when the execution thread jumps between the debugger and
> the debuggee. Not all of that trickery is in place, and not all of what
> is in place works (or could ever work) perfectly.
>
> Some of the related problems are solved in the latest version of the
> debug support functions (from libdbg.a which comes with the djdev
> distribution), to be released with the upcoming version 2.03 of DJGPP.
> In particular, keyboard interrupt is now correctly saved and restored
> by the debugger, if the debuggee hooks it. However, current versions
> or RHIDE are based on older debug support routines, and hence still
> suffer from the problems you describe.
>
> In any way, I don't think that even the latest versions save and
> restore the mouse handler. It strikes me that the easiest way out for
> you would be to invoke RHIDE with the -M switch (which IIRC disables
> the mouse inside RHIDE).
>
> > My question now: Which way uses RHIDE during a breakpoint-event ? ->
> > Which exception-number is called by RHIDE beginning a debugging-
> > session (INT 3 seams wrong)?
>
> It's not INT 3, it's Exception 3. This is a similar, but different
> event, and you cannot hook it with an interrupt handler, you need to
> install an *exception* handler, e.g. with the library function
> __dpmi_set_processor_exception_handler_vector.
>
> > How can i insert an own handler in this
> > procedure for reinstall the default keyboard-handler at the begin of
> > the debugging-session and restore my handlers after all?
>
> You cannot easily do this, and you don't want to, believe me. The DJGPP
> debug support is a notoriously complex machinery; naive hooking of the
> breakpoint exception will most probably totally disrupt the debugger's
> operation. I really don't recommend to use such hacks.
>
> Instead, I suggest to rebuild RHIDE with the newer debug support (you
> can get it from the anonymous CVS access to the DJGPP development
> sources, see http://www.delorie.com/djgpp/cvs.html; you want the file
> src/debug/common/dbgcom.c). If you succeed in building RHIDE, and if
> the problems you describe are still there, and if you can find your
> way through dbgcom.c (don't hesitate to ask question here), then you
> can add some code to dbgcom.c that e.g. saves and restores the mouse
> handler, and then rebuild RHIDE.
- Raw text -