Mail Archives: djgpp-workers/2003/02/07/05:56:16

Date: Fri, 7 Feb 2003 12:53:38 +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: <>
Message-ID: <>
References: <10302061441 DOT AA20682 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 Thu, 6 Feb 2003, Charles Sandmann wrote:

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

Right, I was only thinking of the case where the program just happens
to have too small stack size by default.

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

Actually, I think we may assume that if a function is compiled with
-fstack-check then it will only be called when esp points to the normal
application stack.  In that case it's sufficient to simply compare esp
against __djgpp_stack_limit, so there's no need for any new global

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

Won't that cause an exception even now?  But I'll keep that in mind.

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

I considered that as well, but then ebp really can't be used for
anything but the frame pointer, and switching to and from the exception
stack becomes more complicated.

Esa Peuha
student of mathematics at the University of Helsinki

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019