Mail Archives: djgpp/1999/12/15/04:18:29
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 -