Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings.

[Iain Sandoe <idsandoe@googlemail.com>]

> On 25 Aug 2021, at 19:22, H.J. Lu <hjl.tools@gmail.com> wrote:
> 
> On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe <idsandoe@googlemail.com> wrote:
>> 
>> 
>> 
>>> On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>> 
>>> On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> 
>>>> On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe <idsandoe@googlemail.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On 20 Aug 2021, at 11:29, Richard Sandiford <richard.sandiford@arm.com> 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 += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
>>>>>>> 
>>>>>>> OK. I have misgivings about this - the problem is that:
>>>>>>> 
>>>>>>> -fPIC -fno-PIE != -fno-PIE -fPIC,  which is not obvious to many folks - who expect that
>>>>>>> the “last edition of a flag will be the one in force”.
>>>>>>> 
>>>>>>> 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 (FWIW, I don’t 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_CFLAGS),
>>>>>> which restates whatever the base code model is.
>>>>>> 
>>>>>> If it's the decoupling you're worried about, then an alternative would
>>>>>> be to have:
>>>>>> 
>>>>>> NO_PIE_CFLAGS="-fno-PIE \$(CODE_MODEL_CFLAGS)”
>>>>> 
>>>>> I’d 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 addresses each time).
>>>>> 
>>>>> B. It’s certainly not obvious to me why we need to build code to run on $build to be no-PIE - I don’t 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=71934
>>>> 
>>>>> ——
>>>>> 
>>>>> 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 $(BUILD_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 Darwin we cannot build static linked code for user-space processes.
>>>>> 
>>>>> in any event that’s inconsistent (unless there’s 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 would request PIC code (for example) for things to run on $build?
>>> 
>>> We need to fix
>>> 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
>> 
>> 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 —disable-libstdcxx-pch).
>> 
>> The PR doesn’t explain:
>> 
>> 1. why it’s 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’t see answers to the questions above in that thead or the PR - there is nothing so far in this that explains why no-PIE has been forced on for the stuff in gcc/build

but OK.. I’ll look at implementing the patch suggested by Richard,
thanks
Iain