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 <amo...@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 <amo...@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'll ask a question of you. Have you reviewed the patch and found anything wrong with it? -- Alan Modra Australia Development Lab, IBM
