Sender: bill AT taniwha DOT tssc DOT co DOT nz
Message-ID: <36AB924F.38E4FD79@taniwha.tssc.co.nz>
Date: Mon, 25 Jan 1999 10:36:15 +1300
From: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.2.0-final i486)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
CC: Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
        Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject: Re: Exceptions in v2.02
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990124120302 DOT 11155A-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> I'm consistently observing some very weird phenomena with exceptions and
> signals in v2.02.  For example, when a SIGALRM aborts the program,
> sometimes ES != DS (I even saw SS != DS a couple of times).  In other
> cases, SS:ESP in the traceback point to the exception stack instead of
> the application stack.
> 
> Did anybody else see such problems?

Not me, but then I haven;t actually used DJGPP in almost a year.

> Usually these problems happened for me when there were more than a single
> signal that could be raised.  For example, the problems with SIGALRM
> above happened when the program in question was compiled with -pg.
> 
> Any ideas?

The signal is comming in while the app is still in the exception code?

> One problem that particularly bothers me is that I cannot find the place
> in the exception-handling code where we switch back to the normal
> application stack.  Can somebody point my stupid self to the right spot?
> I cannot analyze these problems without knowing where they should have
> been handled.

I believe this is handled by the longjump code.  As I remember it, *all*
registers are restored from the longjump buffer, including the seg regs.

Bill
-- 
Leave others their otherness.