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 :-) ). And given that there's no possibility to express "and please only _add_ to the cmdline options" (which implies also being able to override values from the cmdline with -fno-xxx or other -fyyy options) I consider our current GCC behaviour for the optimize attribute basically unusable. (One work-around would be to define a macro containing all cmdline options in string form in the build system. Obviously that's a silly solution.) So, yeah, IMHO the semantics of that attribute should be revised to be more useful by default (with the possibility to express the current behaviour, for whomever would like to have that (but who?)). Ciao, Michael.