This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New -fstack-check implementation


> 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.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]