From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: RHIDE problem Date: Thu, 16 Dec 1999 10:33:13 +0200 Organization: NetVision Israel Lines: 36 Message-ID: References: <839kfd$mjv$1 AT nntp5 DOT atl DOT mindspring DOT net> NNTP-Posting-Host: is.elta.co.il Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: news.netvision.net.il 945333097 19888 199.203.121.2 (16 Dec 1999 08:31:37 GMT) X-Complaints-To: abuse AT netvision DOT net DOT il NNTP-Posting-Date: 16 Dec 1999 08:31:37 GMT X-Sender: eliz AT is In-Reply-To: <839kfd$mjv$1@nntp5.atl.mindspring.net> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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 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.