Re: [PATCH 03/18] Do not stack-protect ifunc resolvers.

[Nix <nix at esperi dot org dot uk>]

On 9 Mar 2016, Mike Frysinger told this:

> On 08 Mar 2016 13:50, Nix wrote:
>> +AC_CACHE_CHECK(if $CC accepts -fno-stack-protector with \
>> +__attribute__ ((__optimize__)), libc_cv_cc_no_stack_protector, [dnl
>> +cat > conftest.c <<EOF
>> +void
>> +__attribute__ ((__optimize__ ("-fno-stack-protector")))
>> +foo (void) {}
>> +EOF
>
> actually, which versions of gcc *don't* support this ?  if it's in gcc-4.7
> and newer, then we don't need this test as we require that already.

Good question. The worrying thing is that support for
__attribute__((__optimize__)) may not be enough: IIRC, that attribute
was not exactly perfectly functional in the first release or two after
it landed, IIRC.

Let's see...

... GCC 4.4?! OK, way older than I remembered. We can definitely drop
this: there have been fixes to fix things like target-specific options
with __attribute__((__optimize__)) right up until recently, but nothing
that would perturb -fno-stack-protector (and nothing at *all* between
4.6.x and 4.8.x, and I know 4.8.x works).

So I'll drop this bit.

(Technically this makes libc_cv_ssp useless too, because
-fstack-protector is *much* older than __attribute__((__optimize__)),
but it's consistent with the checks for -fstack-protector-strong and
-all to have it there, and those are much newer and still not
consistently supported on all targets. I can tear libc_cv_ssp and
have_ssp out as well if you think it worth doing.)

-- 
NULL && (void)