From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10302061441.AA20682@clio.rice.edu>
Subject:	Re: Checking for stack overflow
To:	djgpp-workers AT delorie DOT com
Date:	Thu, 6 Feb 2003 08:41:59 -0600 (CST)
In-Reply-To:	<Pine.OSF.4.51.0302061333090.25864@sirppi.helsinki.fi> from "Esa A E Peuha" at Feb 06, 2003 02:04:02 PM
X-Mailer:	ELM [version 2.5 PL2]
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

> > Why not jump to __djgpp_traceback_exit instead?
> 
> After printing "out of stack", you mean?  Maybe, but the traceback
> doesn't seem very useful to me in this case.

Sure, it shows what routine caused the overflow, and if the overflow
was caused by a big automatic allocation or some recursive routine
which has recursed forever.

> > I don't think we should have this working by default, only given some
> > switch to GCC.  Stack checking is a run-time overhead, so we shouldn't
> > force it on users, IMHO.
> 
> Gcc already has -fstack-check for this; it just doesn't do anything
> useful currently.

I think it would be good to support this.  I'd be willing to help hack
the needed global variables out if you did the rest.  We really need
to be able to make sure that the right signed/unsigned behavior is
done with this or it's not very useful (big automatic arrays can cause
ESP to not only go into data or code, but actually below 0 and into
uncommitted space).

> Here's another thought: how about having an uncommitted memory page just
> below the stack?  Then stack overflow would be just like dereferencing a
> null pointer; caught with no run-time overhead (but only on DOS machines
> unfortunately).

A single page only helps the recursive type behavior - even an automatic
allocation of 5K may miss the page if it's not all used.  I actually
provided the uncommitted memory block once to someone (it can be done in
user code) - you set the stack size to be 2X normal size then uncommit
the bottom 1/2.  It caught many problems, but missed some, and was a 
DOS only fix.

There once was latent support in V2.x for the same hack we used in V1.x to
detect this - the stack selector is marked as expand down and has a limit
which is the "bottom" instead of the top.   This works well in many cases,
has no run-time issues - but doesn't work with -fomit-frame-pointer.  There
are places you must be careful about assumption that SS=DS (not true in
limit sense anymore since SS is restricted).  The DS alias stuff is 
similar to what is needed (or may work as-is) - and was based on the 
GO32 hack to make the SS limit work.  This can also be tested in user 
mode if I remember correctly (but was last probably done in V2.0 beta 3)
and also works fine on all platforms, not just DOS.

- Raw text -