Re: [PATCH] Fix pr80044, -static and -pie insanity, and pr81170

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Jul 17, 2017 at 9:02 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Jul 17, 2017 at 06:01:47AM -0700, H.J. Lu wrote:
>> On Mon, Jul 17, 2017 at 5:33 AM, Alan Modra <amodra@gmail.com> wrote:
>> > On Sat, Jul 15, 2017 at 06:32:40AM -0700, H.J. Lu wrote:
>> >> On Thu, Jun 22, 2017 at 8:28 AM, Alan Modra <amodra@gmail.com> wrote:
>> >> > PR80044 notes that -static and -pie together behave differently when
>> >> > gcc is configured with --enable-default-pie as compared to configuring
>> >> > without (or --disable-default-pie).  This patch removes that
>> >> > difference.  In both cases you now will have -static completely
>> >> > overriding -pie.
>> >> >
>> >> > Fixing this wasn't quite as simple as you'd expect, due to poor
>> >> > separation of functionality.  PIE_SPEC didn't just mean that -pie was
>> >> > on explicitly or by default, but also -r and -shared were *not* on.
>> >> > Fortunately the three files touched by this patch are the only places
>> >> > PIE_SPEC and NO_PIE_SPEC are used, so it isn't too hard to see that
>> >> > the reason PIE_SPEC and NO_PIE_SPEC are not inverses is the use of
>> >> > PIE_SPEC in LINK_PIE_SPEC.  So, move the inelegant symmetry breaking
>> >> > addition, to LINK_PIE_SPEC where it belongs.  Doing that showed
>> >> > another problem in gnu-user.h, with PIE_SPEC and NO_PIE_SPEC selection
>> >> > of crtbegin*.o not properly hooked into a chain of if .. elseif ..
>> >> > conditions, which required both PIE_SPEC and NO_PIE_SPEC to exclude
>> >> > -static and -shared.  Fixing that particular problem finally allows
>> >> > PIE_SPEC to serve just one purpose, and NO_PIE_SPEC to disappear.
>> >> >
>> >> > Bootstrapped and regression tested powerpc64le-linux c,c++.  No
>> >> > regressions and a bunch of --enable-default-pie failures squashed.
>> >> > OK mainline and active branches?
>> >> >
>> >> > Incidentally, there is a fairly strong case to be made for adding
>> >> > -static to the -shared, -pie, -no-pie chain of RejectNegative's in
>> >> > common.opt.  Since git 0d6378a9e (svn r48039) 2001-11-15, -static has
>> >> > done more than just the traditional "prevent linking with dynamic
>> >> > libraries", as -static selects crtbeginT.o rather than crtbegin.o
>> >> > on GNU systems.  Realizing this is what led me to close pr80044, which
>> >> > I'd opened with the aim of making -pie -static work together (with the
>> >> > traditional meaning of -static).  I don't that is worth doing, but
>> >> > mention pr80044 in the changelog due to fixing the insane output
>> >> > produced by -pie -static with --disable-default-pie.
>> >> >
>> >>
>> >> On x86-64, without --enable-default-pie, "-static -pie" and "-pie -static"
>> >> never worked since both -static and -pie are passed to linker, which
>> >> uses libc.a to build PIE.
>> >
>> > Yes, it's broken.
>>
>> This behavior may be useful for static PIE when libc.a is compiled with
>> -fPIE.
>
> Building a PIE from static archives using -static -pie or -pie -static
> right now is broken, even if the archives are compiled -fpie/PIE.
> I've looked into fixing it, and decided it wasn't worth the effort.
> There are multiple problems.  See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80044#c1
>
> One reason why I believe it isn't worth fixing is that the meaning of
> -static has changed over the years, from "link using static archives"
> to "produce a static executable", and most certainly the meaning of
> -static and -pie together is not clear.  I'll cite gold behaviour as
> evidence: -static with -pie results in an error from gold.  See
> https://sourceware.org/ml/binutils/2012-02/msg00119.html and following
> discussion.
>
>> >>  With --enable-default-pie, -static and -pie
>> >> override each other.
>> >
>> > No they don't.  -static overrides -pie.
>> >
>> >>  What does your patch do on x86-64?  Make
>> >> with and without --enable-default-pie behave the same?
>> >
>> > Yes, as I said in my original post first paragraph.
>> >
>> >>  Does it
>> >> mean that both fail to create executable?
>> >
>> > I try to leave that sort of patch to those better qualified.
>> > Bootstrap and regression testing on x86_64-linux both
>> > --enable-default-pie and --disable-default-pie was complete June 23.
>> >
>>
>> What is the new behavior?  The old  --disable-default-pie or old
>> --enable-default-pie?
>
> You are asking questions to which the answer is given in the very
> first paragraph posted in this thread, if you knew the current
> --enable-default-pie behaviour.  -static overrides -pie.  ie. current
> --enable-default-pie behaviour is unchanged.
>
>> Will static PIE be supported if libc is
>> compiled with -fPIE by default?
>
> I covered this above, if you're asking about -static and -pie
> together.  Unsupported both before and after my patch.  You *can* link
> a working PIE from -fPIE archives, if that is what you want, with
> "-pie -Wl,-Bstatic", both before and after my patch.

I am working on compiling libc.a in glibc with -fPIE and building static
PIE.  This creates static executable with PIE:

gcc -nostdlib -nostartfiles -static -o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/sln -pie
-Wl,--no-dynamic-linker
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crt1.o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crti.o `gcc
--print-file-name=crtbeginS.o`
/export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/sln.o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/static-stubs.o
 -Wl,--start-group
/export/build/gnu/glibc-static-pie/build-x86_64-linux/libc.a -lgcc
-Wl,--end-group `gcc  --print-file-name=crtendS.o`
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crtn.o

Currently, it only works with gcc configured with -disable-default-pie.
With --enable-default-pie, I got

[hjl@gnu-tools-1 build-x86_64-linux]$ /usr/gcc-7.1.1-x32-pie/bin/gcc
-nostdlib -nostartfiles -static -o /tmp/sln -pie
-Wl,--no-dynamic-linker
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crt1.o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crti.o `gcc
--print-file-name=crtbeginS.o`
/export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/sln.o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/elf/static-stubs.o
 -Wl,--start-group
/export/build/gnu/glibc-static-pie/build-x86_64-linux/libc.a -lgcc
-Wl,--end-group `gcc  --print-file-name=crtendS.o`
/export/build/gnu/glibc-static-pie/build-x86_64-linux/csu/crtn.o
/export/build/gnu/glibc-static-pie/build-x86_64-linux/libc.a(dl-support.o):
In function `elf_machine_load_address':
/export/gnu/import/git/sources/glibc/elf/../sysdeps/x86_64/dl-machine.h:59:
undefined reference to `_DYNAMIC'
/export/build/gnu/glibc-static-pie/build-x86_64-linux/libc.a(dl-support.o):
In function `elf_get_dynamic_info':
/export/gnu/import/git/sources/glibc/elf/get-dynamic-info.h:48:
undefined reference to `_DYNAMIC'
collect2: error: ld returned 1 exit status
[hjl@gnu-tools-1 build-x86_64-linux]$

Will your change fix it?

-- 
H.J.