Extend -fstack-protector-strong to cover calls with return slot

Florian Weimer fweimer@redhat.com
Tue Jan 7 12:51:00 GMT 2014

On 01/03/2014 10:43 PM, Florian Weimer wrote:

>> Lastly, I wonder if gimple_call_return_slot_opt_p is really what you are
>> after, why does NRV matter here?
> The C code we generate does not construct the returned value in place
> (presumably because the partial write would be visible with threads,
> longjmp etc.), unlike the C++ code.
> That's why I'm interested in instrumenting NRV-able calls only.  But
> gimple_call_return_slot_opt_p doesn't actually give me that.  The GIMPLE
> from the C test case looks like this (before and after applying your
> proposal):

I thought about this some more and I think it makes sense to add the 
instrumentation each time the return slot is used, both for C and C++. 
We don't if the called function is implemented in C or C++, so 
language-specific instrumentation is not entirely accurate.

I'm attaching a second version of the patch, splitting out the decl and 
bb analysis and using is_gimple_call.  Bootstrapped and 
regression-tested on x86_64-redhat-linux-gnu.

Florian Weimer / Red Hat Product Security Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssp-strong-return-slot.patch
Type: text/x-patch
Size: 4169 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140107/1189aa52/attachment.bin>

More information about the Gcc-patches mailing list