From: "Marp" Newsgroups: comp.os.msdos.djgpp Subject: Re: RHIDE problem Date: Wed, 15 Dec 1999 21:57:39 -0500 Organization: MindSpring Enterprises Lines: 66 Message-ID: <839kfd$mjv$1@nntp5.atl.mindspring.net> References: NNTP-Posting-Host: c7.b7.cf.25 X-Server-Date: 16 Dec 1999 02:57:49 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 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.