From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118385 invoked by alias); 17 Jul 2017 13:01:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 118188 invoked by uid 89); 17 Jul 2017 13:01:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-oi0-f68.google.com Received: from mail-oi0-f68.google.com (HELO mail-oi0-f68.google.com) (209.85.218.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 13:01:49 +0000 Received: by mail-oi0-f68.google.com with SMTP id n2so17729397oig.3 for ; Mon, 17 Jul 2017 06:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yBx9C9aive6IusuvIbQRLiEEIyOz328krRUc96ALlNg=; b=nVR7r5ZnJn0QqFQtA+KpPBYZEqp239x94EHYK35uZCaDZzW1oyXUzYi4HMC3v5lszH oNWP758fSiwvtcPMQIdisf601JvFj0+IarANe7Z6p8fgVs3zqoo36w0kNvKy24Y2wBjG gvPtqfg5oQnkTtUZz1c41T94GBijRx5H20FNrznBwBE0gj9vqSBlK0tR2F4BwFIkLkx/ cG2WGI0udF3l4xPaHHzhHvGhjPeH1b+59Ef38UlQYmBe1cMttt9c3Gnmmwpw+1BugjeQ 7beLDJh8G82eEPSfFyqrrbhajOtqFw7gpw+Mp0zEPJaWwpcuzssaC9ZatvzGa9VgVZDB jBYw== X-Gm-Message-State: AIVw1113FmpL+jTQQgvklOyTxOWXQb66PX8m+pAQxVAqmLckc79mfZbf fgguAmnyGP1SNUVD+9eGklHqCF5+1sgf X-Received: by 10.202.8.85 with SMTP id 82mr13155691oii.195.1500296508060; Mon, 17 Jul 2017 06:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.140.71 with HTTP; Mon, 17 Jul 2017 06:01:47 -0700 (PDT) In-Reply-To: <20170717123325.GG14520@bubble.grove.modra.org> References: <20170622152859.GG8406@bubble.grove.modra.org> <20170717123325.GG14520@bubble.grove.modra.org> From: "H.J. Lu" Date: Mon, 17 Jul 2017 13:01:00 -0000 Message-ID: Subject: Re: [PATCH] Fix pr80044, -static and -pie insanity, and pr81170 To: Alan Modra Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00974.txt.bz2 On Mon, Jul 17, 2017 at 5:33 AM, Alan Modra 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 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.