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.
