From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b7566e485e23e171 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Mandatory stack check (was: Changing discriminants...) Date: 1996/08/08 Message-ID: #1/1 X-Deja-AN: 172961430 references: <3209AC29.3E21@lmtas.lmco.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-08-08T00:00:00+00:00 List-Id: In article <3209AC29.3E21@lmtas.lmco.com>, Ken Garlington 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