Date: Wed, 15 Dec 1999 09:08:50 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Gero Timann cc: djgpp AT delorie DOT com Subject: Re: RHIDE problem In-Reply-To: <385679CF.1344CA2D@online.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.