On 11/11/2016 11:41 AM, Jiong Wang wrote:
On 24/10/16 16:22, Jeff Law wrote:
Asserting couldn't hurt. I'd much rather have the compiler issue an
error, ICE or somesuch than silently not generate a call to the stack
protector fail routine.
Hi Jeff,
I have just send out the other patch which accelerates
-fstack-protector on
AArch64, more background information there at:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01168.html
Confirms what I suspected :-)
Previous, I was emptying three target insns/hooks, and was relying GCC to
optimize all remaining SSP runtime stuff out. I am thinking it's
better and
safer that GCC allow one backend to disable the default SSP runtime
cleanly,
so the backend does't need to rely on optimization level, and libssp
is not
needed at all optimization level.
In this new patch, I introduced a new target macro for SSP to allow one
backend GCC's default SSP runtime generation be disabled.
How does this looks to you?
Thanks.
gcc/
2016-11-11 Jiong Wang <jiong.w...@arm.com>
* function.c (expand_function_end): Guard stack_protect_epilogue
with
ENABLE_DEFAULT_SSP_RUNTIME.
* cfgexpand.c (pass_expand::execute): Likewise guard for
stack_protect_prologue.
* defaults.h (ENABLE_DEFAULT_SSP_RUNTIME): New macro. Default
set to 1.
* doc/tm.texi.in (Misc): Documents ENABLE_DEFAULT_SSP_RUNTIME.
* doc/tm.texi: Regenerate.
Like Joseph, I think this should be a hook rather than a new target
macro. I do think it's closer to the right track though (separation of
access to the guard from the rest of the SSP runtime bits).
Jeff
