> On 25 Aug 2021, at 19:22, H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe <idsan...@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.to...@gmail.com> wrote:
>>>>
>>>> On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe <idsan...@googlemail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 20 Aug 2021, at 11:29, Richard Sandiford <richard.sandif...@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
