Re: [PATCH 09/12] Link various tests with -fno-stack-protector.

[Florian Weimer <fweimer at redhat dot com>]

On 12/15/2016 03:54 PM, Nix wrote:
> On 15 Dec 2016, Florian Weimer uttered the following:
>
> > On 11/28/2016 01:32 PM, Nix wrote:
> >
> > > diff --git a/elf/Makefile b/elf/Makefile
> > > index daf0ebd..7588ca0 100644
> > > --- a/elf/Makefile
> > > +++ b/elf/Makefile
> > > @@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so
> > >  		  $< -Wl,-F,$(objpfx)filtmod2.so
> > >  $(objpfx)filter: $(objpfx)filtmod1.so
> > >
> > > +# These do not link against libc.
> > > +CFLAGS-filtmod1.c = $(no-stack-protector)
> > > +CFLAGS-filtmod2.c = $(no-stack-protector)
> >
> > Is this really necessary for filtmod2.c?
>
> I assumed it was wisest to link it with the same options as the library
> it was the filter for. It might be harmless, though -- I'll drop it and
> find out!
>
> > > diff --git a/stdlib/Makefile b/stdlib/Makefile
> > > index 3cce9d9..6d7586e 100644
> > > --- a/stdlib/Makefile
> > > +++ b/stdlib/Makefile
> > > @@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed)
> > >
> > >  $(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps)
> > >  	$(build-module)
> > > +# This is not only not in libc, it's not even linked with it.
> > > +CFLAGS-tst-putenvmod.c += $(no-stack-protector)
> >
> > I think this papers over an actual failure. Based on my build logs,
> > tst-putenvmod.so is properly linked against libc (including
> > libc_nonshared.a).
>
> Hmm! I'll take that out and have a look. Maybe __attribute
> ((constructor)) is causing problems, though I'd assume this would work
> fine or other stack-protector users would be howling.
>
> Much of this may be residual fallout from the days before we had the
> stack-protector symbol export from libc/internal refs inside libc
> working right.
>
> > > diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile
> > > index 6d99284..fbe138f 100644
> > > --- a/sysdeps/x86_64/Makefile
> > > +++ b/sysdeps/x86_64/Makefile
> > > @@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test)
> > >  test-extras += tst-quadmod1pie tst-quadmod2pie
> > >  extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o
> > >
> > > +CFLAGS-tst-quad1pie.c = $(no-stack-protector)
> > > +CFLAGS-tst-quad2pie.c = $(no-stack-protector)
> >
> > This looks like a genuine test failure as well.  I'll try to reproduce it, after I have tracked down the more catastrophic MIPS
> > build failure …
>
> Yeah: they link against libc as well. Maybe I was misled by an
> old-binutils problem back in the early days of this patch.
>
> I'll try pulling this out as well...
>
> (the MIPS one is easily explained by my not having a MIPS available and
> having done zero testing on it. God only knows what system-dependent
> horrors we need to work around. I haven't even *used* a MIPS bigger than
> my wifi router since the early '90s... :) )

Joseph added build-many-glibcs.py recently, which really helps 
diagnosing build-time failures and ABI issues.

The MIPS failure appears to be similar to the ia64 failure because the 
R_MIPS_CALL16 relocation in __stack_chk_fail_local triggers it:

000f4590 <__stack_chk_fail_local>:
   f4590:       27bdfff0        addiu   sp,sp,-16
   f4594:       ffbc0000        sd      gp,0(sp)
   f4598:       3c1c0000        lui     gp,0x0
                        f4598: R_MIPS_GPREL16   __stack_chk_fail_local
                        f4598: R_MIPS_SUB       *ABS*
                        f4598: R_MIPS_HI16      *ABS*
   f459c:       0399e021        addu    gp,gp,t9
   f45a0:       279c0000        addiu   gp,gp,0
                        f45a0: R_MIPS_GPREL16   __stack_chk_fail_local
                        f45a0: R_MIPS_SUB       *ABS*
                        f45a0: R_MIPS_LO16      *ABS*
   f45a4:       8f990000        lw      t9,0(gp)
                        f45a4: R_MIPS_CALL16    .text+0xf4590
   f45a8:       ffbf0008        sd      ra,8(sp)
   f45ac:       0320f809        jalr    t9
                        f45ac: R_MIPS_JALR      __stack_chk_fail
   f45b0:       00000000        nop

So I'll construct a new series with your STACK_PROTECTOR_LEVEL patch and 
see where things go with that.

Thanks,
Florian