Date:	Wed, 12 Feb 2003 11:12:49 +0200 (EET)
From:	Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Sender:	peuha AT sirppi DOT helsinki DOT fi
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Checking for stack overflow
In-Reply-To:	<10302111440.AA01702@clio.rice.edu>
Message-ID:	<Pine.OSF.4.51.0302121051330.32166@sirppi.helsinki.fi>
References:	<10302111440 DOT AA01702 AT clio DOT rice DOT edu>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 11 Feb 2003, Charles Sandmann wrote:

> I would rather call it something like __djgpp_stack_top (it may not
> be related at all to heap) if we did it.

I committed patch for __djgpp_stack_top; we should have it anyway
because __djgpp_stack_limit + _stklen won't be the real top of stack if
it's not aligned to 8-byte boundary.

> I think the change to "jb" fixes the signed-ness issue - so I'm not
> sure this is really needed.

I don't understand.  Do you mean that a single unsigned comparsion
against __djgpp_stack_limit is enough?  It's not; it's even worse than
the single signed comparsion (if esp ever wraps below zero, the unsigned
comparsion will never detect it, while the signed one will usually do).

> The new top limit will causes problems with interrupt wrappers since
> they live in heap space - fix is not to compile anything used in
> a wrapper with check stack

Yes, anything that puts esp outside the application stack certainly
shouldn't be compiled with -fstack-check.

> I'd be interested to see this working, see how much of a run-time
> impact it has, and how much checking the second limit changes the
> run-time performance.

I'll provide two version of patched gcc, one with one signed comparsion
and the other with two unsigned ones.

-- 
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/

- Raw text -