Date: Fri, 7 Feb 2003 12:53:38 +0200 (EET) From: Esa A E Peuha 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: References: <10302061441 DOT AA20682 AT clio DOT rice DOT edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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/