On Wed, Aug 25, 2021 at 8:30 PM Iain Sandoe via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > > 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
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’ll look at implementing the patch suggested by Richard, > thanks > Iain > > >
