Date: Sun, 20 Dec 1998 11:29:01 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: sjoerd DOT s DOT bakker AT tip DOT nl cc: djgpp AT delorie DOT com Subject: Re: My INT 1 handler crashes under Windows 95 In-Reply-To: <367d35d7.28434683@news.worldonline.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Thu, 17 Dec 1998 sjoerd DOT s DOT bakker AT tip DOT nl wrote: > If I do a longjmp, then I will lose track of the executing program and > I want to trace each instruction. Longjmp restores the stack-segment > and -pointer, so there would be no way to get back to the instruction > following the one that caused SIGTRAP. If you want a trace facility, you might consider looking at the DJGPP debug support (files in the src/debug directory in the djlsr202.zip archive). They implement a similar facility for INT 3. This is tricky, and requires quite a lot of assembly and interrupt hooking, but it does work. I believe you could use similar techniques for INT 1 as well. Btw, you could implement tracing by moving the debug instruction in the INT 3 handler, or by setting the debug registers to generate INT 3 at the address of the next instruction. This is how tracing works in the debuggers supported by DJGPP. The advantage of this method is that it already works, so you only need to write a front end (or use an existing debugger ;-). > I had tried a normal return from the signal handler, but I got a > SIGTRAP registerdump with an error message about the handler not being > able to return... as to be expected since the cause of the exception > (TRAP-flag set) still exists after returning. Correct. That is why I said you need to longjmp.