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.  */
> # 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?)).


Reply via email to