Re: [PATCH] New -fstack-check implementation

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Sun, Mar 30, 2008 at 1:39 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > Can you elaborate on the design?
>
>  Stack checking is made up of 2 parts: "static" stack checking, i.e. checking
>  for the static part of the frame, and "dynamic" stack checking, i.e. checking
>  for dynamic stack allocations.  In both cases, the checking must be done
>  prior to the stack allocation itself to be correct, in particular prior to
>  the frame allocation in the former case, i.e. in the prologue.  The old
>  implementation is incorrect in that it doesn't do proper static stack
>  checking (except on the Alpha) but instead sort of emulates it with dynamic
>  stack checking in the parent function; this works only for small frames.
>
>  The patch adds the static stack checking part to the major architectures by
>  means of back-end specific support.  Technically it's emitted in the RTL
>  prologue as an UNSPEC_VOLATILE instruction and output inline.  If there is
>  no such support for a given architecture, the checking falls back on the old
>  implementation.
>
>  The patch also adds 2 stack checking methods, in addition to the 2 existing
>  ones which are stack probes and checking routine: stack probes with moving
>  stack pointer (for x86{-64}/Linux) and stack limits (for VxWorks).
>
>
>  > Why do you think we cannot remove the old code and call -fstack-check
>  > unsupported on architectures that do not have the required target support?
>
>  The patch unbreaks the old implementation, in the sense that it brings it at
>  least on par with what it was in the 3.x series, although its limitations are
>  still there, so removing it altogether would be sort of a feature regression.
>  We still use the old implementation at AdaCore for some "secondary" platforms.
>  Moreover the new implementation reuses the old implementation's code for the
>  dynamic checking part so the net gain would be small.

Thanks for the explanation.  If you split the patch into fixing static
stack checking
and the rest would it make the fixing static stack checking mostly middle-end
independent?  I think fixing static statck checking should be uncontroversical
and splitting it out for easier architecture maintainers review would be nice.

Is there a possibility to add C testcases (maybe architecture specific, for a
popular architecture like x86) to incerase testing coverage of both features?

Thanks,
Richard.