Mail Archives: djgpp-workers/2003/02/07/05:56:16
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 -