delorie.com/archives/browse.cgi   search  
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: <10302061441.AA20682@clio.rice.edu>
Message-ID: <Pine.OSF.4.51.0302071221550.25428@sirppi.helsinki.fi>
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
variable.

> 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
http://www.helsinki.fi/~peuha/

- Raw text -


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