stack overflow

Wed Nov 3 02:32:00 GMT 1999

> Date: Tue, 2 Nov 1999 16:03:44 -0800 (PST)
> From: Tom Tromey <tromey@cygnus.com>
>> >>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:
>> >> At every procedure call, an additional parameter is being passed.
> >> This parameter contains the current stacklimit. On each procedure
> >> entry, the parameter is checked against the current stack pointer.
>> Godmar> On obvious disadvantage of this approach is that it would
> Godmar> undermine the Java==C++ illusion CNI promises. Calling Java
> Godmar> code from separately compiled C/C++ code wouldn't be possible
> Godmar> in a transparent manner.
>> I think we want Java and C++ to look more alike, not less. I'd be
> against this approach on this basis (which really means that it would
> be a last-resort approach). I don't have a better suggestion yet,
> though.

As an example, the ARM Procedure Call Standard (APCS) reserves a
register for the stack limit. The entry sequence of a routine looks
like this:
 cmp sp, limit
 blt overflow
This also allows stacks to be allocated non-contiguously. When a
stack hits its limit, pages can be allocated from a pool and linked
in. The return sequence is simply
 mov fp, sp
so there is no requirement that the stack should be contiguous. This
is also true of many other processors.
Is it really practical to do this in a truly processor (and calling
convention) independent fashion? gcc can be made to reserve a
register for a user, but we'd have to ensure that every tiny bit of
library code was compiled to avoid using the register.
In any case, this isn't really a language specific issue: all
programming languages are affected by this problem. I would have
thought that the Right Way to do this is in gcc itself, so that limit
checking goes into all languages. After all, the stack overflow might
happen in a leaf C routine.
Andrew.