Re: Mandatory stack check (was: Changing discriminants...)

[bobduff@world.std.com (Robert A Duff)]

In article <3209AC29.3E21@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Interesting. Does stack checking typically introduce an extra branch in the
>object code?

I think the implementation Robert is talking about is one that relies on
page-level protection done by the hardware (and hence near-zero cost).
I.e. set the protection of the page just beyond the stack to "no
access", so any reference to it will trap.  So no, it's not an explicit
branch instruction.

The reason this is not implemented in all versions of GNAT is, no doubt,
the fact that the mechanisms for accessing the page tables and whatnot
is different across different operating systems, and across different
hardware.  And gcc, and therefore GNAT, are very reluctant to do damage
to portability (else, how could they support so many targets?).

Also, the code generator has to be pretty careful to get it right.
Suppose, for example, I reference Some_Array(I), and I happens to be
10**9.  Well, that might well get past the protected page, and write
upon some other task's stack.

>... If so, then someone with a requirement to test every object-code
>branch point would have to introduce a test to force a stack overflow for each
>affected code segment (including elaboration), or have to justify why the
>overflow check didn't need to be tested. That could be a little annoying...

Well, this is true in any case.  It doesn't really matter (for testing)
whether stack overflow is detected by an explcit instruction, or by page
protection (causing an implicit jump into the OS).  Either way, if you
want to test all possibilities, you have to worry about it.

The RM says *anything* can raise Storage_Error, which means the amount
of testing involved would be infeasible.  Instead, I think people who
really care about that sort of thing do low-level analysis of the object
code to ensure that Storage_Error is impossible.  This requires using a
subset of the full Ada language.

Note that handling Storage_Error and trying to recover is rather
questionable.  Since anything can raise S_E, and since 11.6 allows the
compiler to play all kinds of tricks, you essentially have to assume
that lots of data structures will be destroyed (see "abnormal" in the
RM) in case of S_E.  And if your data structures are destroyed, what can
you do safely after handling S_E?  It is probably possible to write it
correctly, but most programmers don't understand 11.6(6) deeply enough
to do so, and most programmers are not inclined to worry about it, since
for most programs, it's fine to consider S_E to be a catastrophic
failure that just kills the program.

- Bob