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 -- H.J.
