Date:	Sun, 20 Dec 1998 11:29:01 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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:	<Pine.SUN.3.91.981220112842.27996I-100000@is>
MIME-Version:	1.0
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.

- Raw text -