From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 72F0F385BC23 for ; Wed, 25 Aug 2021 18:22:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72F0F385BC23 Received: by mail-pg1-x529.google.com with SMTP id w8so564341pgf.5 for ; Wed, 25 Aug 2021 11:22:50 -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:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/2MuW4Gf0s2wUg3d+3wgROeO7xVHQgO2xXLC17C6tb8=; b=UJDaQ702D2gpYR+5eY3cZaRbnix/kUjlr0oSPr9Lly0GVRp0dqS66PG97+0GmAKHi8 4jLJppeasV5qrtFwfePKL/QIZOHwbORJJNRcjO+V29t4k8BO/NtLwI34aO96oDBEyAxV YqinRu1BmevUxUvKmH4Wg45GhmyQ33iF5e0e8QISHK1OUR/h9qYES9Tm8sPtWGzXZDDG aZtRbOKVUECWwXdnqvWu3Z2S/RTwcLBmULZ0Kf77wKYRLzLIhXG0RUeF3fWNsb1yp70n qaLb+ParOgrBSPbpTlHExasXaQ0SdZZOkkMiVjh9tHHfkzPKHP/wXMuHkcnVq7awCwGt LqLQ== X-Gm-Message-State: AOAM530b48nuRYdf32fHi4KTu5sdx61mlSDSvV1GgXMX9S9ZY/W+hX/i yQGdHQrAHF0kfx2Qq+qID9+1kbLUlqeKHWzYmfY= X-Google-Smtp-Source: ABdhPJy8WjtknHUUb+G3kG5b02AW6KAlyJPF5otxDp54yzEosgDjaWLqqFdCaF1p9wXttnYxsQ3dOFxi0me4oNZSkrU= X-Received: by 2002:a63:164a:: with SMTP id 10mr43730227pgw.161.1629915769511; Wed, 25 Aug 2021 11:22:49 -0700 (PDT) MIME-Version: 1.0 References: <7F4EA5FF-0CDC-4C0C-BF2B-B276C1A4E434@sandoe.co.uk> <7E483B90-25B7-494C-9BC5-2BC51D2BEB78@sandoe.co.uk> <85254E55-ED0C-4CB8-82E0-B9B2E5EF2E0D@googlemail.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 25 Aug 2021 11:22:13 -0700 Message-ID: Subject: Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings. To: Iain Sandoe Cc: Richard Sandiford , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3024.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 18:23:01 -0000 On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe wrot= e: > > > > > On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches wrote: > > > > On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu wrote: > >> > >> On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe = wrote: > >>> > >>> Hi, > >>> > >>>> On 20 Aug 2021, at 11:29, Richard Sandiford wrote: > >>>> > >>>>>> Maybe it would be easier to have the makefile fragments determine > >>>>>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", "-mdynamic= -no-pic", > >>>>>> etc., and use: > >>>>>> > >>>>>> COMPILER +=3D $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS) > >>>>> > >>>>> OK. I have misgivings about this - the problem is that: > >>>>> > >>>>> -fPIC -fno-PIE !=3D -fno-PIE -fPIC, which is not obvious to many f= olks - who expect that > >>>>> the =E2=80=9Clast edition of a flag will be the one in force=E2=80= =9D. > >>>>> > >>>>> So the PIE-ness and the PIC-ness are decoupled in the configury but= they need to be > >>>>> ordered specifically for targets that want PIC code by default (FWI= W, I don=E2=80=99t think Darwin > >>>>> is the only default-PIC case here, from discussions on irc). > >>>> > >>>> Yeah, that's what the above was supposed to achieve. In other words= , > >>>> if you force non-PIE, you also need to follow that by $(CODE_MODEL_C= FLAGS), > >>>> which restates whatever the base code model is. > >>>> > >>>> If it's the decoupling you're worried about, then an alternative wou= ld > >>>> be to have: > >>>> > >>>> NO_PIE_CFLAGS=3D"-fno-PIE \$(CODE_MODEL_CFLAGS)=E2=80=9D > >>> > >>> I=E2=80=99d like to ask a couple of questions (of HJ who introduced t= he no-PIE logic) before implementing this. > >>> > >>> A. We use no-PIE for cc1* because that is needed to handle the PCH im= plementation (which relies on the executables being loaded at the same addr= esses each time). > >>> > >>> B. It=E2=80=99s certainly not obvious to me why we need to build code= to run on $build to be no-PIE - I don=E2=80=99t see any such dependencies = in the generators etc. > >>> > >>> - So Question1 - HJ what was the motivation for making the XXX_BUILD= _XXX adopt no-PIE? > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71934 > >> > >>> =E2=80=94=E2=80=94 > >>> > >>> Independently of this we seem to be building the objects for $host th= us: > >>> > >>> $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. > >>> > >>> but we build for $build thus: > >>> > >>> $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BUIL= D_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) > >>> > >>> which means that code model flags in $ALL_CXXFLAGS are overridden for= $build, but active for $host > >>> ^^ this is actually what causes the Darwin build fail - since on Darw= in we cannot build static linked code for user-space processes. > >>> > >>> in any event that=E2=80=99s inconsistent (unless there=E2=80=99s a re= ason that it should be different). > >>> > >>> ---- > >>> > >>> below are extracts from gcc/Makefile *on linux* which demonstrates th= e different ordering. > >>> > >>> AFAICT, > >>> NO_PIE_CFLAGS_FOR_BUILD, NO_PIE_FLAG_FOR_BUILD are dead variables? > > ^^ what was the intention for these? > > >>> Question 2 : HJ, what was your intention for how a configuration woul= d request PIC code (for example) for things to run on $build? > > > > We need to fix > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71934 > > The need for no-PIE for the exectuables that consume PCH is completely cl= ear (but a target can choose not to use PCH - and configure =E2=80=94disabl= e-libstdcxx-pch). > > The PR doesn=E2=80=99t explain: > > 1. why it=E2=80=99s being enabled for the generators (and other $build co= de) which do not use PCH (AFAIK) > > 2. why the flags ordering is different for $build and $host. > > I am completely happy to make the fix Richard suggested - but we seem to = be adding complexity rather than simplifying things; as noted in the PR the= re are targets that cannot use no-PIE and therefore have to disable PCH any= way. Please follow: https://gcc.gnu.org/pipermail/gcc-patches/2015-October/432180.html -- H.J.