Date: Mon, 25 Jan 1999 09:17:20 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
cc: djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: Exceptions in v2.02
In-Reply-To: <36AB924F.38E4FD79@taniwha.tssc.co.nz>
Message-ID: <Pine.SUN.3.91.990125091522.6041D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com


Thanks for the feedback.

On Mon, 25 Jan 1999, Bill Currie wrote:

> > 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?

How can this be?  The exception-handling code in exceptn.S fixes the
DS limit and restores ES and SS as one of the first things, before it
jumps to any application code, and that code runs with interrupts
disabled (I think).

> > 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.

What longjmp?  The one near the end of __djgpp_exception_processor?
If so, this is a disaster: it means that if I define a non-trivial
signal handler, it runs entirely on the exception stack (which is
quite small), because `longjmp' is called after `raise'.

Imagine that, while the signal handler runs, another signal arrives, and 
another--soon enough we will overflow the exception stack.

Charles, is this true?