From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 4CDAB3858402 for ; Thu, 26 Aug 2021 06:41:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CDAB3858402 Received: by mail-ej1-x631.google.com with SMTP id me10so3828233ejb.11 for ; Wed, 25 Aug 2021 23:41:08 -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=+q3KJI2m5f38ADmqvobD9FUw6QkZ+CHhNKd1pmvGXso=; b=Dz6dG3xrTlsUt2j5E0woQQpl0DImaeXLkgq8ypnaq5eE5YWchafUik76vciw/KU3kY 43kSSBZ0JyvFweAbJSii1SQf2Ik5xMJbtwhtqjfn3sCm6CBiZwiZol2cw5pFm4LU8/PC SCeZy0LMFIXrSSItDUiSLS6zBZoh58edr0RMuHg97Wn4/4FqDIHYN2oAp1qMtUE5t49C 1M0I/H8syeLy3VgWBSz1lxPg8XHwxnDRd5rORYafrXY68K/0RaNqhj+MDziky6XH5mWq aEaa5risVTX3rpA6qsmR/q/eWeBKH7/R7ZSRRrzKOOWLdWgIiTMXSIHCX5wYMCpxQbWA HlYw== X-Gm-Message-State: AOAM531bggehi+63wcOYVoXvxUcGP4XQmQIRrzJHOg+70eTu0ngqaM1m QmCp4RyKK8xP7BxHAM6/PQysgkoYLU4EhQCoywc= X-Google-Smtp-Source: ABdhPJyvKPhSLCgQwNQX6DVMUDkvN1IU+d07PU2F4RcLSgGIgoQ6WQIL0HWZj7etcbJKbwuFVN+beMUxznpe2NMUBms= X-Received: by 2002:a17:906:27d5:: with SMTP id k21mr2740024ejc.235.1629960067289; Wed, 25 Aug 2021 23:41:07 -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: Richard Biener Date: Thu, 26 Aug 2021 08:40:56 +0200 Message-ID: Subject: Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings. To: Iain Sandoe Cc: "H.J. Lu" , Richard Sandiford , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 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: Thu, 26 Aug 2021 06:41:19 -0000 On Wed, Aug 25, 2021 at 8:30 PM Iain Sandoe via Gcc-patches wrote: > > > > > On 25 Aug 2021, at 19:22, H.J. Lu wrote: > > > > On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe = wrote: > >> > >> > >> > >>> 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 determin= e > >>>>>>>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", "-mdynam= ic-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= folks - 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 b= ut they need to be > >>>>>>> ordered specifically for targets that want PIC code by default (F= WIW, 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 wor= ds, > >>>>>> if you force non-PIE, you also need to follow that by $(CODE_MODEL= _CFLAGS), > >>>>>> which restates whatever the base code model is. > >>>>>> > >>>>>> If it's the decoupling you're worried about, then an alternative w= ould > >>>>>> 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= the no-PIE logic) before implementing this. > >>>>> > >>>>> A. We use no-PIE for cc1* because that is needed to handle the PCH = implementation (which relies on the executables being loaded at the same ad= dresses each time). > >>>>> > >>>>> B. It=E2=80=99s certainly not obvious to me why we need to build co= de to run on $build to be no-PIE - I don=E2=80=99t see any such dependencie= s in the generators etc. > >>>>> > >>>>> - So Question1 - HJ what was the motivation for making the XXX_BUI= LD_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 = thus: > >>>>> > >>>>> $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. > >>>>> > >>>>> but we build for $build thus: > >>>>> > >>>>> $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BU= ILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) > >>>>> > >>>>> which means that code model flags in $ALL_CXXFLAGS are overridden f= or $build, but active for $host > >>>>> ^^ this is actually what causes the Darwin build fail - since on Da= rwin we cannot build static linked code for user-space processes. > >>>>> > >>>>> in any event that=E2=80=99s inconsistent (unless there=E2=80=99s a = reason that it should be different). > >>>>> > >>>>> ---- > >>>>> > >>>>> below are extracts from gcc/Makefile *on linux* which demonstrates = the 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 wo= uld 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= clear (but a target can choose not to use PCH - and configure =E2=80=94dis= able-libstdcxx-pch). > >> > >> The PR doesn=E2=80=99t explain: > >> > >> 1. why it=E2=80=99s being enabled for the generators (and other $build= code) 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 = there are targets that cannot use no-PIE and therefore have to disable PCH = anyway. > > > > Please follow: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2015-October/432180.html > > I don=E2=80=99t see answers to the questions above in that thead or the P= R - there is nothing so far in this that explains why no-PIE has been force= d on for the stuff in gcc/build I think there's no good reason for -fno-PIE for exectuables built for build (if done correctly, that is). So it would indeed be nice to simplify things here. Richard. > but OK.. I=E2=80=99ll look at implementing the patch suggested by Richard= , > thanks > Iain > > >