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

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

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.

>>  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?  Will static PIE be supported if libc is
compiled with -fPIE by default?

-- 
H.J.