* Michael Matz:
> Hello,
>
> On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
>
>> > The patch adds new no_stack_protect attribute. The change is requested
>> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
>> > Unlike Clang, I chose to name it no_stack_protect because we already
>> > have stack_protect attribute (used with -fstack-protector-explicit).
>> >
>> > First part of the patch contains a small refactoring of an enum, second
>> > implements the functionality.
>>
>> In glibc, we already have this:
>>
>> /* Used to disable stack protection in sensitive places, like ifunc
>> resolvers and early static TLS init. */
>> #ifdef HAVE_CC_NO_STACK_PROTECTOR
>> # define inhibit_stack_protector \
>> __attribute__ ((__optimize__ ("-fno-stack-protector")))
>> #else
>> # define inhibit_stack_protector
>> #endif
>>
>> Is it broken?
>
> Depends on what your expectations are. It completely overrides all
> options given on the command line (including things like
> fno-omit-frame-pointer and -O2!). At least I was very surprised by that
> even though the current docu can be read that way; if you're similarly
> surprised, then yes, the above is broken, it does not only disable stack
> protection (but also e.g. all optimizations, despite the attributes name
> :-) ).
Yes, that would qualify as broken.
This is not what I observe with gcc-9.3.1-2.fc31.x86_64 from Fedora.
-O2 still has an effect. So does -fcf-protection.
-fno-omit-frame-pointer does not work for me at all for some reason, the
frame pointer is always missing?
Not sure what is going on here …
Thanks,
Florian
