| Message ID | 7F4EA5FF-0CDC-4C0C-BF2B-B276C1A4E434@sandoe.co.uk |
|---|---|
| State | New |
| Headers | show |
| Series | configure: Allow a host makefile fragment to override PIE flag settings. | expand |
Iain Sandoe <iain@sandoe.co.uk> writes: > Hi, > > This concerns the settings of flags (using the host makefile fragment) for > tools that will run on the host. > > At present the (no)PIE flags are computed in gcc/configure but it is not > possible to override them (either from higher level Makefile or from the > command line). Secondly the ordering of placement of flags assumes > ELF semantics are OK for ordering of -fno-PIE and -fPIC. > > For Darwin, this introduces problems if fno-PIE causes PIC to be switched > off and the bootstrap compiler does not support mdynamic-no-pic (which > is the case when we bootstrap a 32b toolchain with clang). This causes > the host files to be built '-static' which is not legal for user-space > code, and the build terminates with illegal relocations (so that bootstrap > fails). > > This patch: > > 1. Allows the computed PIE flags to be overridden by the top level > configure. > > 2. Allows a host fragment to set values on the basis of the configured > host platform/version. > > 3. Sets suitable values for the Darwin cases that currently fail. > > tested on i686,powerpc,x86-64-darwin, x86_64, powerpc64-linux, > OK for master? > > thanks > Iain > > Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> > > ChangeLog: > > * Makefile.in: Regenerated. > * Makefile.tpl: Add PIE flags to HOST_EXPORTS and > POST_STAGE1_HOST_EXPORTS as specified by the host makefile > fragment. > > config/ChangeLog: > > * mh-darwin: Specify suitable PIE/PIC flags for 32b Darwin > hosts. > > gcc/ChangeLog: > > * configure: Regenerate. > * configure.ac: Allow top level configure to override assumed > PIE flags. > --- > Makefile.in | 14 ++++++++++++++ > Makefile.tpl | 14 ++++++++++++++ > config/mh-darwin | 20 ++++++++++++++++---- > gcc/configure | 4 ++-- > gcc/configure.ac | 4 ++-- > 5 files changed, 48 insertions(+), 8 deletions(-) > > diff --git a/Makefile.tpl b/Makefile.tpl > index 9adf4f94728..9523be5a761 100644 > --- a/Makefile.tpl > +++ b/Makefile.tpl > @@ -576,6 +576,20 @@ all: > @host_makefile_frag@ > ### > > +# Allow host makefile fragment to override PIE settings. > +ifneq ($(STAGE1_NO_PIE_CFLAGS),) > + HOST_EXPORTS += export NO_PIE_CFLAGS="$(STAGE1_NO_PIE_CFLAGS)"; > +endif > +ifneq ($(STAGE1_NO_PIE_FLAG),) > + HOST_EXPORTS += export NO_PIE_FLAG="$(STAGE1_NO_PIE_FLAG)"; > +endif > +ifneq ($(BOOT_NO_PIE_CFLAGS),) > + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_CFLAGS="$(BOOT_NO_PIE_CFLAGS)"; > +endif > +ifneq ($(BOOT_NO_PIE_FLAG),) > + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_FLAG="$(BOOT_NO_PIE_FLAG)"; > +endif Not really my area, but: Is the NO_PIE_FLAG just for completeness? It didn't look like the patch overrode that. Might be easier to leave it out if so, to avoid any risk of accidentally having an empty variable. 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) This avoids mixing the autoconf-derived variable with the host override. I think we need to stick to the traditional sh foo=X; export foo style used elsewhere. "export foo=X" is a bash extension. It also might be better to have: STAGE1_CODE_MODEL_CFLAGS = BOOT_CODE_MODEL_CFLAGS = CODE_MODEL_CFLAGS = in Makefile.tpl (just before the config/ includes) and then override them in mh-darwin. We can then include the exports unconditionally, like with other variables. I think we should export them for the host too (via HOST_EXPORTS). We could add {STAGE1,BOOT}_CODE_MODEL_CFLAGS to the main {STAGE1,BOOT}_{C,CXX}FLAGS in Makefile.tpl. It looks like that might simplify some of the existing mh-darwin code a bit. Like I say, not my area, so feel free to ignore :-) Thanks, Richard > + > # This is the list of directories that may be needed in RPATH_ENVVAR > # so that programs built for the target machine work. > TARGET_LIB_PATH = [+ FOR target_modules +][+ > diff --git a/config/mh-darwin b/config/mh-darwin > index b72835ae953..d3c357a0574 100644 > --- a/config/mh-darwin > +++ b/config/mh-darwin > @@ -7,6 +7,13 @@ > # We use Werror, since some versions of clang report unknown command line flags > # as a warning only. > > +# In addition, all versions of clang released to date treat -fno-PIE in -m32 > +# compilations as switching PIC code off too, which means that -fno-PIE, > +# without -mdynamic-no-pic produces broken relocations (and we cannot enable > +# -mdynamic-no-pic because the inverse setting doesn't work). To work around > +# this, we need to ensure that the no-PIE option is followed by -fPIE, when > +# the compiler does not support mdynamic-no-pic. > + > # We only need to determine this for the host tool used to build stage1 (or a > # non-bootstrapped compiler), later stages will be built by GCC which supports > # the required flags. > @@ -24,23 +31,28 @@ endif > @if gcc-bootstrap > ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) > STAGE1_CFLAGS += -mdynamic-no-pic > +STAGE1_NO_PIE_CFLAGS = -fno-PIE > else > STAGE1_CFLAGS += -fPIC > +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC > endif > ifeq (${host_shared},no) > # Add -mdynamic-no-pic to later stages when we know it is built with GCC. > BOOT_CFLAGS += -mdynamic-no-pic > +BOOT_NO_PIE_CFLAGS = -fno-PIE > +else > +BOOT_NO_PIE_CFLAGS = -fno-PIE -fPIC > endif > @endif gcc-bootstrap > > @unless gcc-bootstrap > ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) > -# FIXME: we should also enable this for cross and non-bootstrap builds but > -# that needs amendment to libcc1. > -# CFLAGS += -mdynamic-no-pic > -# CXXFLAGS += -mdynamic-no-pic > +CFLAGS += -mdynamic-no-pic > +CXXFLAGS += -mdynamic-no-pic > +STAGE1_NO_PIE_CFLAGS = -fno-PIE > else > CFLAGS += -fPIC > CXXFLAGS += -fPIC > +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC > endif > @endunless gcc-bootstrap > > diff --git a/gcc/configure.ac b/gcc/configure.ac > index ad8fa5a4604..fad9b27879e 100644 > --- a/gcc/configure.ac > +++ b/gcc/configure.ac > @@ -7580,7 +7580,7 @@ AC_CACHE_CHECK([for -fno-PIE option], > [gcc_cv_c_no_fpie=no]) > CXXFLAGS="$saved_CXXFLAGS"]) > if test "$gcc_cv_c_no_fpie" = "yes"; then > - NO_PIE_CFLAGS="-fno-PIE" > + NO_PIE_CFLAGS=${NO_PIE_CFLAGS-"-fno-PIE"} > fi > AC_SUBST([NO_PIE_CFLAGS]) > > @@ -7594,7 +7594,7 @@ AC_CACHE_CHECK([for -no-pie option], > [gcc_cv_no_pie=no]) > LDFLAGS="$saved_LDFLAGS"]) > if test "$gcc_cv_no_pie" = "yes"; then > - NO_PIE_FLAG="-no-pie" > + NO_PIE_FLAG=${NO_PIE_FLAG-"-no-pie"} > fi > AC_SUBST([NO_PIE_FLAG])
Hi Richard, > On 20 Aug 2021, at 09:39, Richard Sandiford <richard.sandiford@arm.com> wrote: > > Iain Sandoe <iain@sandoe.co.uk> writes: >> This concerns the settings of flags (using the host makefile fragment) for >> tools that will run on the host. >> >> At present the (no)PIE flags are computed in gcc/configure but it is not >> possible to override them (either from higher level Makefile or from the >> command line). Secondly the ordering of placement of flags assumes >> ELF semantics are OK for ordering of -fno-PIE and -fPIC. >> >> For Darwin, this introduces problems if fno-PIE causes PIC to be switched >> off and the bootstrap compiler does not support mdynamic-no-pic (which >> is the case when we bootstrap a 32b toolchain with clang). This causes >> the host files to be built '-static' which is not legal for user-space >> code, and the build terminates with illegal relocations (so that bootstrap >> fails). >> >> This patch: >> >> 1. Allows the computed PIE flags to be overridden by the top level >> configure. >> >> 2. Allows a host fragment to set values on the basis of the configured >> host platform/version. >> >> 3. Sets suitable values for the Darwin cases that currently fail. >> >> tested on i686,powerpc,x86-64-darwin, x86_64, powerpc64-linux, >> OK for master? >> >> thanks >> Iain >> >> Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> >> >> ChangeLog: >> >> * Makefile.in: Regenerated. >> * Makefile.tpl: Add PIE flags to HOST_EXPORTS and >> POST_STAGE1_HOST_EXPORTS as specified by the host makefile >> fragment. >> >> config/ChangeLog: >> >> * mh-darwin: Specify suitable PIE/PIC flags for 32b Darwin >> hosts. >> >> gcc/ChangeLog: >> >> * configure: Regenerate. >> * configure.ac: Allow top level configure to override assumed >> PIE flags. >> --- >> Makefile.in | 14 ++++++++++++++ >> Makefile.tpl | 14 ++++++++++++++ >> config/mh-darwin | 20 ++++++++++++++++---- >> gcc/configure | 4 ++-- >> gcc/configure.ac | 4 ++-- >> 5 files changed, 48 insertions(+), 8 deletions(-) >> >> diff --git a/Makefile.tpl b/Makefile.tpl >> index 9adf4f94728..9523be5a761 100644 >> --- a/Makefile.tpl >> +++ b/Makefile.tpl >> @@ -576,6 +576,20 @@ all: >> @host_makefile_frag@ >> ### >> >> +# Allow host makefile fragment to override PIE settings. >> +ifneq ($(STAGE1_NO_PIE_CFLAGS),) >> + HOST_EXPORTS += export NO_PIE_CFLAGS="$(STAGE1_NO_PIE_CFLAGS)"; >> +endif >> +ifneq ($(STAGE1_NO_PIE_FLAG),) >> + HOST_EXPORTS += export NO_PIE_FLAG="$(STAGE1_NO_PIE_FLAG)"; >> +endif >> +ifneq ($(BOOT_NO_PIE_CFLAGS),) >> + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_CFLAGS="$(BOOT_NO_PIE_CFLAGS)"; >> +endif >> +ifneq ($(BOOT_NO_PIE_FLAG),) >> + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_FLAG="$(BOOT_NO_PIE_FLAG)"; >> +endif > > Not really my area, but: thanks for a very helpful review :) > Is the NO_PIE_FLAG just for completeness? Well, the NO_PIE_FLAG is used (the flags that are passed down lose the distinction of stage1/post-stage1), it’s the BOOT_NO_PIE_FLAG that is not used in this initial patch - however, it is used when we consider the enable_host_shared in a later patch. The idea was to produce a general facility even if the first user of it did not need all elements. > It didn't look like the > patch overrode that. Might be easier to leave it out if so, to avoid > any risk of accidentally having an empty variable. Yeah, perhaps trying to be general without a use-case, fails to test adequately. … since the host shared stuff is now applied I’ll revise this consider that too so that both the stage1 and post-stage1 cases should be exercised. > 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). Thus the mechanism I adopted was to ensure that the no-PIE setting could be adjusted to make sure that PIC was enforced where needed (the probably non-obvious aspect of this is that mdynamic-no-pic only happens to work because it doesn’t exist for ELF and thus doesn’t get switched off by the no-PIE logic). All very fragile, sadly. In fact, (on Darwin) PIE implies PIC - it is one case where ELF semantics are at odds with Mach-O in a non-easy manner (I have caught most cases in darwin_override_options, but that obv. doesn’t work at configure-time since the bootstrap complier is outside our control). I would be concerned that any decoupled flag could become reordered w.r.t the no-PIE and break things again, but I guess we could assume that testing would catch that. Trying to couple the PIC and PIE configs might be possible but I suspect it’s a deeper rabbit hole than I have cycles to explore at the present. > This avoids mixing the autoconf-derived variable with the host override. > > I think we need to stick to the traditional sh > > foo=X; export foo > > style used elsewhere. "export foo=X" is a bash extension. good catch; something that doesn’t trigger on darwin and linux testing but would be reported the day after the patch was applied ;) > > It also might be better to have: > > STAGE1_CODE_MODEL_CFLAGS = > BOOT_CODE_MODEL_CFLAGS = > CODE_MODEL_CFLAGS = > > in Makefile.tpl (just before the config/ includes) and then override > them in mh-darwin. We can then include the exports unconditionally, > like with other variables. that’s a good idea it should make things more readable... > > I think we should export them for the host too (via HOST_EXPORTS). … that is done, in fact, it’s probably just not the most readable config fragment. > > We could add {STAGE1,BOOT}_CODE_MODEL_CFLAGS to the main > {STAGE1,BOOT}_{C,CXX}FLAGS in Makefile.tpl. It looks like > that might simplify some of the existing mh-darwin code a bit. > > Like I say, not my area, so feel free to ignore :-) I’ll make a revision to implement the changes to avoid bash-isms and the simplification of the exports; for switching to use of CODE_MODEL_CFLAGS, I’m open to persuasion that it can be done in a non-fragile manner. thanks for the review, Iain > > Thanks, > Richard > >> + >> # This is the list of directories that may be needed in RPATH_ENVVAR >> # so that programs built for the target machine work. >> TARGET_LIB_PATH = [+ FOR target_modules +][+ >> diff --git a/config/mh-darwin b/config/mh-darwin >> index b72835ae953..d3c357a0574 100644 >> --- a/config/mh-darwin >> +++ b/config/mh-darwin >> @@ -7,6 +7,13 @@ >> # We use Werror, since some versions of clang report unknown command line flags >> # as a warning only. >> >> +# In addition, all versions of clang released to date treat -fno-PIE in -m32 >> +# compilations as switching PIC code off too, which means that -fno-PIE, >> +# without -mdynamic-no-pic produces broken relocations (and we cannot enable >> +# -mdynamic-no-pic because the inverse setting doesn't work). To work around >> +# this, we need to ensure that the no-PIE option is followed by -fPIE, when >> +# the compiler does not support mdynamic-no-pic. >> + >> # We only need to determine this for the host tool used to build stage1 (or a >> # non-bootstrapped compiler), later stages will be built by GCC which supports >> # the required flags. >> @@ -24,23 +31,28 @@ endif >> @if gcc-bootstrap >> ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) >> STAGE1_CFLAGS += -mdynamic-no-pic >> +STAGE1_NO_PIE_CFLAGS = -fno-PIE >> else >> STAGE1_CFLAGS += -fPIC >> +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC >> endif >> ifeq (${host_shared},no) >> # Add -mdynamic-no-pic to later stages when we know it is built with GCC. >> BOOT_CFLAGS += -mdynamic-no-pic >> +BOOT_NO_PIE_CFLAGS = -fno-PIE >> +else >> +BOOT_NO_PIE_CFLAGS = -fno-PIE -fPIC >> endif >> @endif gcc-bootstrap >> >> @unless gcc-bootstrap >> ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) >> -# FIXME: we should also enable this for cross and non-bootstrap builds but >> -# that needs amendment to libcc1. >> -# CFLAGS += -mdynamic-no-pic >> -# CXXFLAGS += -mdynamic-no-pic >> +CFLAGS += -mdynamic-no-pic >> +CXXFLAGS += -mdynamic-no-pic >> +STAGE1_NO_PIE_CFLAGS = -fno-PIE >> else >> CFLAGS += -fPIC >> CXXFLAGS += -fPIC >> +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC >> endif >> @endunless gcc-bootstrap >> >> diff --git a/gcc/configure.ac b/gcc/configure.ac >> index ad8fa5a4604..fad9b27879e 100644 >> --- a/gcc/configure.ac >> +++ b/gcc/configure.ac >> @@ -7580,7 +7580,7 @@ AC_CACHE_CHECK([for -fno-PIE option], >> [gcc_cv_c_no_fpie=no]) >> CXXFLAGS="$saved_CXXFLAGS"]) >> if test "$gcc_cv_c_no_fpie" = "yes"; then >> - NO_PIE_CFLAGS="-fno-PIE" >> + NO_PIE_CFLAGS=${NO_PIE_CFLAGS-"-fno-PIE"} >> fi >> AC_SUBST([NO_PIE_CFLAGS]) >> >> @@ -7594,7 +7594,7 @@ AC_CACHE_CHECK([for -no-pie option], >> [gcc_cv_no_pie=no]) >> LDFLAGS="$saved_LDFLAGS"]) >> if test "$gcc_cv_no_pie" = "yes"; then >> - NO_PIE_FLAG="-no-pie" >> + NO_PIE_FLAG=${NO_PIE_FLAG-"-no-pie"} >> fi >> AC_SUBST([NO_PIE_FLAG])
Iain Sandoe <iain@sandoe.co.uk> writes: > Hi Richard, >> 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 was going to suggest that originally, but thought the above might be simpler to follow later. Thanks, Richard
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? —— 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? Question 2 : HJ, what was your intention for how a configuration would request PIC code (for example) for things to run on $build? thanks Iain ------- ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \ $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \ -- # Native compiler for the build machine and its switches. CC_FOR_BUILD = $(CC) CXX_FOR_BUILD = $(CXX) NO_PIE_CFLAGS_FOR_BUILD = NO_PIE_FLAG_FOR_BUILD = BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS) BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS) BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS) # Native compiler that we use. This may be C++ some day. COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) # Native linker that we use. LINKER_FOR_BUILD = $(CXX_FOR_BUILD) BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS) # Native linker and preprocessor flags. For x-fragment overrides. BUILD_LDFLAGS=$(LDFLAGS) BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG) BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG) BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include $(CPPINC) $(CPPFLAGS) -- # This is the variable actually used when we compile. If you change this, # you probably want to update BUILD_CFLAGS in configure.ac ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \ build/%.o : # dependencies provided by explicit rule later $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \ -o $@ $< ^^^^ this has $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) NO_PIE_CFLAGS_FOR_BUILD is apparently ignored # Rule for the generator programs: $(genprog:%=build/gen%$(build_exeext)): build/gen%$(build_exeext): build/gen%.o $(BUILD_LIBDEPS) +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \ $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) -- build/genversion$(build_exeext): build/genversion.o +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \ build/genversion.o -o $@ ========= # The name of the compiler to use. COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) # If HOST_LIBS is set, then the user is controlling the libraries to -- CET_HOST_FLAGS = -fcf-protection COMPILER += $(CET_HOST_FLAGS) -- # We don't want to compile the compilers with -fPIE, it make PCH fail. COMPILER += $(NO_PIE_CFLAGS) -- # A list of all the language-specific executables. COMPILERS = gnat1$(exeext) cc1$(exeext) cc1plus$(exeext) d21$(exeext) f951$(exeext) go1$(exeext) lto1$(exeext) cc1obj$(exeext) cc1objplus$(exeext) -- # Native compiler that we use. This may be C++ some day. COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) -- # This is the variable to use when using $(COMPILER). ALL_COMPILERFLAGS = $(ALL_CXXFLAGS) -- COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@ This is : $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(@D)/$(DEPDIR)/$(*F).TPo POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(*F).TPo $(@D)/$(DEPDIR)/$(*F).Po .cc.o .c.o: $(COMPILE) $< $(POSTCOMPILE)
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? > > Question 2 : HJ, what was your intention for how a configuration would request PIC code (for example) for things to run on $build? > > thanks > Iain > > ------- > > > ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \ > $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \ > > -- > # Native compiler for the build machine and its switches. > CC_FOR_BUILD = $(CC) > CXX_FOR_BUILD = $(CXX) > NO_PIE_CFLAGS_FOR_BUILD = > NO_PIE_FLAG_FOR_BUILD = > BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE > BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE > BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS) > BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS) > BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS) > > # Native compiler that we use. This may be C++ some day. > COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) > BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) > > # Native linker that we use. > LINKER_FOR_BUILD = $(CXX_FOR_BUILD) > BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS) > > # Native linker and preprocessor flags. For x-fragment overrides. > BUILD_LDFLAGS=$(LDFLAGS) > BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG) > BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG) > BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ > -I$(srcdir)/../include $(CPPINC) $(CPPFLAGS) > -- > # This is the variable actually used when we compile. If you change this, > # you probably want to update BUILD_CFLAGS in configure.ac > ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \ > > build/%.o : # dependencies provided by explicit rule later > $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \ > -o $@ $< > > ^^^^ this has > $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) > NO_PIE_CFLAGS_FOR_BUILD is apparently ignored > > # Rule for the generator programs: > $(genprog:%=build/gen%$(build_exeext)): build/gen%$(build_exeext): build/gen%.o $(BUILD_LIBDEPS) > +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \ > $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) > > -- > build/genversion$(build_exeext): build/genversion.o > +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \ > build/genversion.o -o $@ > ========= > > # The name of the compiler to use. > COMPILER = $(CXX) > COMPILER_FLAGS = $(CXXFLAGS) > # If HOST_LIBS is set, then the user is controlling the libraries to > -- > CET_HOST_FLAGS = -fcf-protection > COMPILER += $(CET_HOST_FLAGS) > > -- > # We don't want to compile the compilers with -fPIE, it make PCH fail. > COMPILER += $(NO_PIE_CFLAGS) > > -- > # A list of all the language-specific executables. > COMPILERS = gnat1$(exeext) cc1$(exeext) cc1plus$(exeext) d21$(exeext) f951$(exeext) go1$(exeext) lto1$(exeext) cc1obj$(exeext) cc1objplus$(exeext) > > -- > # Native compiler that we use. This may be C++ some day. > COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) > BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) > > -- > > # This is the variable to use when using $(COMPILER). > ALL_COMPILERFLAGS = $(ALL_CXXFLAGS) > > -- > > COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@ > > This is : > $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. > > COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(@D)/$(DEPDIR)/$(*F).TPo > POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(*F).TPo $(@D)/$(DEPDIR)/$(*F).Po > > .cc.o .c.o: > $(COMPILE) $< > $(POSTCOMPILE) >
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? > > > > 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 first. H.J. > > thanks > > Iain > > > > ------- > > > > > > ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \ > > $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \ > > > > -- > > # Native compiler for the build machine and its switches. > > CC_FOR_BUILD = $(CC) > > CXX_FOR_BUILD = $(CXX) > > NO_PIE_CFLAGS_FOR_BUILD = > > NO_PIE_FLAG_FOR_BUILD = > > BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE > > BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE > > BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS) > > BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS) > > BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS) > > > > # Native compiler that we use. This may be C++ some day. > > COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) > > BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) > > > > # Native linker that we use. > > LINKER_FOR_BUILD = $(CXX_FOR_BUILD) > > BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS) > > > > # Native linker and preprocessor flags. For x-fragment overrides. > > BUILD_LDFLAGS=$(LDFLAGS) > > BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG) > > BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG) > > BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ > > -I$(srcdir)/../include $(CPPINC) $(CPPFLAGS) > > -- > > # This is the variable actually used when we compile. If you change this, > > # you probably want to update BUILD_CFLAGS in configure.ac > > ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \ > > > > build/%.o : # dependencies provided by explicit rule later > > $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \ > > -o $@ $< > > > > ^^^^ this has > > $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) > > NO_PIE_CFLAGS_FOR_BUILD is apparently ignored > > > > # Rule for the generator programs: > > $(genprog:%=build/gen%$(build_exeext)): build/gen%$(build_exeext): build/gen%.o $(BUILD_LIBDEPS) > > +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \ > > $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) > > > > -- > > build/genversion$(build_exeext): build/genversion.o > > +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \ > > build/genversion.o -o $@ > > ========= > > > > # The name of the compiler to use. > > COMPILER = $(CXX) > > COMPILER_FLAGS = $(CXXFLAGS) > > # If HOST_LIBS is set, then the user is controlling the libraries to > > -- > > CET_HOST_FLAGS = -fcf-protection > > COMPILER += $(CET_HOST_FLAGS) > > > > -- > > # We don't want to compile the compilers with -fPIE, it make PCH fail. > > COMPILER += $(NO_PIE_CFLAGS) > > > > -- > > # A list of all the language-specific executables. > > COMPILERS = gnat1$(exeext) cc1$(exeext) cc1plus$(exeext) d21$(exeext) f951$(exeext) go1$(exeext) lto1$(exeext) cc1obj$(exeext) cc1objplus$(exeext) > > > > -- > > # Native compiler that we use. This may be C++ some day. > > COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) > > BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) > > > > -- > > > > # This is the variable to use when using $(COMPILER). > > ALL_COMPILERFLAGS = $(ALL_CXXFLAGS) > > > > -- > > > > COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@ > > > > This is : > > $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. > > > > COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(@D)/$(DEPDIR)/$(*F).TPo > > POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(*F).TPo $(@D)/$(DEPDIR)/$(*F).Po > > > > .cc.o .c.o: > > $(COMPILE) $< > > $(POSTCOMPILE) > > > > > -- > H.J.
> 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. thanks Iain > > first. > > H.J. >>> thanks >>> Iain >>> >>> ------- >>> >>> >>> ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \ >>> $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \ >>> >>> -- >>> # Native compiler for the build machine and its switches. >>> CC_FOR_BUILD = $(CC) >>> CXX_FOR_BUILD = $(CXX) >>> NO_PIE_CFLAGS_FOR_BUILD = >>> NO_PIE_FLAG_FOR_BUILD = >>> BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE >>> BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE >>> BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS) >>> BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS) >>> BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS) >>> >>> # Native compiler that we use. This may be C++ some day. >>> COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) >>> BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) >>> >>> # Native linker that we use. >>> LINKER_FOR_BUILD = $(CXX_FOR_BUILD) >>> BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS) >>> >>> # Native linker and preprocessor flags. For x-fragment overrides. >>> BUILD_LDFLAGS=$(LDFLAGS) >>> BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG) >>> BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG) >>> BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ >>> -I$(srcdir)/../include $(CPPINC) $(CPPFLAGS) >>> -- >>> # This is the variable actually used when we compile. If you change this, >>> # you probably want to update BUILD_CFLAGS in configure.ac >>> ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \ >>> >>> build/%.o : # dependencies provided by explicit rule later >>> $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \ >>> -o $@ $< >>> >>> ^^^^ this has >>> $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS) >>> NO_PIE_CFLAGS_FOR_BUILD is apparently ignored >>> >>> # Rule for the generator programs: >>> $(genprog:%=build/gen%$(build_exeext)): build/gen%$(build_exeext): build/gen%.o $(BUILD_LIBDEPS) >>> +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \ >>> $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS) >>> >>> -- >>> build/genversion$(build_exeext): build/genversion.o >>> +$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \ >>> build/genversion.o -o $@ >>> ========= >>> >>> # The name of the compiler to use. >>> COMPILER = $(CXX) >>> COMPILER_FLAGS = $(CXXFLAGS) >>> # If HOST_LIBS is set, then the user is controlling the libraries to >>> -- >>> CET_HOST_FLAGS = -fcf-protection >>> COMPILER += $(CET_HOST_FLAGS) >>> >>> -- >>> # We don't want to compile the compilers with -fPIE, it make PCH fail. >>> COMPILER += $(NO_PIE_CFLAGS) >>> >>> -- >>> # A list of all the language-specific executables. >>> COMPILERS = gnat1$(exeext) cc1$(exeext) cc1plus$(exeext) d21$(exeext) f951$(exeext) go1$(exeext) lto1$(exeext) cc1obj$(exeext) cc1objplus$(exeext) >>> >>> -- >>> # Native compiler that we use. This may be C++ some day. >>> COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) >>> BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS) >>> >>> -- >>> >>> # This is the variable to use when using $(COMPILER). >>> ALL_COMPILERFLAGS = $(ALL_CXXFLAGS) >>> >>> -- >>> >>> COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) -o $@ >>> >>> This is : >>> $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc. >>> >>> COMPILE = $(COMPILE.base) -MT $@ -MMD -MP -MF $(@D)/$(DEPDIR)/$(*F).TPo >>> POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(*F).TPo $(@D)/$(DEPDIR)/$(*F).Po >>> >>> .cc.o .c.o: >>> $(COMPILE) $< >>> $(POSTCOMPILE) >>> >> >> >> -- >> H.J. > > > > -- > H.J.
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 -- H.J.
> 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
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.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 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 > > >
diff --git a/Makefile.tpl b/Makefile.tpl index 9adf4f94728..9523be5a761 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -576,6 +576,20 @@ all: @host_makefile_frag@ ### +# Allow host makefile fragment to override PIE settings. +ifneq ($(STAGE1_NO_PIE_CFLAGS),) + HOST_EXPORTS += export NO_PIE_CFLAGS="$(STAGE1_NO_PIE_CFLAGS)"; +endif +ifneq ($(STAGE1_NO_PIE_FLAG),) + HOST_EXPORTS += export NO_PIE_FLAG="$(STAGE1_NO_PIE_FLAG)"; +endif +ifneq ($(BOOT_NO_PIE_CFLAGS),) + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_CFLAGS="$(BOOT_NO_PIE_CFLAGS)"; +endif +ifneq ($(BOOT_NO_PIE_FLAG),) + POSTSTAGE1_HOST_EXPORTS += export NO_PIE_FLAG="$(BOOT_NO_PIE_FLAG)"; +endif + # This is the list of directories that may be needed in RPATH_ENVVAR # so that programs built for the target machine work. TARGET_LIB_PATH = [+ FOR target_modules +][+ diff --git a/config/mh-darwin b/config/mh-darwin index b72835ae953..d3c357a0574 100644 --- a/config/mh-darwin +++ b/config/mh-darwin @@ -7,6 +7,13 @@ # We use Werror, since some versions of clang report unknown command line flags # as a warning only. +# In addition, all versions of clang released to date treat -fno-PIE in -m32 +# compilations as switching PIC code off too, which means that -fno-PIE, +# without -mdynamic-no-pic produces broken relocations (and we cannot enable +# -mdynamic-no-pic because the inverse setting doesn't work). To work around +# this, we need to ensure that the no-PIE option is followed by -fPIE, when +# the compiler does not support mdynamic-no-pic. + # We only need to determine this for the host tool used to build stage1 (or a # non-bootstrapped compiler), later stages will be built by GCC which supports # the required flags. @@ -24,23 +31,28 @@ endif @if gcc-bootstrap ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) STAGE1_CFLAGS += -mdynamic-no-pic +STAGE1_NO_PIE_CFLAGS = -fno-PIE else STAGE1_CFLAGS += -fPIC +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC endif ifeq (${host_shared},no) # Add -mdynamic-no-pic to later stages when we know it is built with GCC. BOOT_CFLAGS += -mdynamic-no-pic +BOOT_NO_PIE_CFLAGS = -fno-PIE +else +BOOT_NO_PIE_CFLAGS = -fno-PIE -fPIC endif @endif gcc-bootstrap @unless gcc-bootstrap ifeq (${BOOTSTRAP_TOOL_CAN_USE_MDYNAMIC_NO_PIC},true) -# FIXME: we should also enable this for cross and non-bootstrap builds but -# that needs amendment to libcc1. -# CFLAGS += -mdynamic-no-pic -# CXXFLAGS += -mdynamic-no-pic +CFLAGS += -mdynamic-no-pic +CXXFLAGS += -mdynamic-no-pic +STAGE1_NO_PIE_CFLAGS = -fno-PIE else CFLAGS += -fPIC CXXFLAGS += -fPIC +STAGE1_NO_PIE_CFLAGS = -fno-PIE -fPIC endif @endunless gcc-bootstrap diff --git a/gcc/configure.ac b/gcc/configure.ac index ad8fa5a4604..fad9b27879e 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -7580,7 +7580,7 @@ AC_CACHE_CHECK([for -fno-PIE option], [gcc_cv_c_no_fpie=no]) CXXFLAGS="$saved_CXXFLAGS"]) if test "$gcc_cv_c_no_fpie" = "yes"; then - NO_PIE_CFLAGS="-fno-PIE" + NO_PIE_CFLAGS=${NO_PIE_CFLAGS-"-fno-PIE"} fi AC_SUBST([NO_PIE_CFLAGS]) @@ -7594,7 +7594,7 @@ AC_CACHE_CHECK([for -no-pie option], [gcc_cv_no_pie=no]) LDFLAGS="$saved_LDFLAGS"]) if test "$gcc_cv_no_pie" = "yes"; then - NO_PIE_FLAG="-no-pie" + NO_PIE_FLAG=${NO_PIE_FLAG-"-no-pie"} fi AC_SUBST([NO_PIE_FLAG])
Hi, This concerns the settings of flags (using the host makefile fragment) for tools that will run on the host. At present the (no)PIE flags are computed in gcc/configure but it is not possible to override them (either from higher level Makefile or from the command line). Secondly the ordering of placement of flags assumes ELF semantics are OK for ordering of -fno-PIE and -fPIC. For Darwin, this introduces problems if fno-PIE causes PIC to be switched off and the bootstrap compiler does not support mdynamic-no-pic (which is the case when we bootstrap a 32b toolchain with clang). This causes the host files to be built '-static' which is not legal for user-space code, and the build terminates with illegal relocations (so that bootstrap fails). This patch: 1. Allows the computed PIE flags to be overridden by the top level configure. 2. Allows a host fragment to set values on the basis of the configured host platform/version. 3. Sets suitable values for the Darwin cases that currently fail. tested on i686,powerpc,x86-64-darwin, x86_64, powerpc64-linux, OK for master? thanks Iain Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> ChangeLog: * Makefile.in: Regenerated. * Makefile.tpl: Add PIE flags to HOST_EXPORTS and POST_STAGE1_HOST_EXPORTS as specified by the host makefile fragment. config/ChangeLog: * mh-darwin: Specify suitable PIE/PIC flags for 32b Darwin hosts. gcc/ChangeLog: * configure: Regenerate. * configure.ac: Allow top level configure to override assumed PIE flags. --- Makefile.in | 14 ++++++++++++++ Makefile.tpl | 14 ++++++++++++++ config/mh-darwin | 20 ++++++++++++++++---- gcc/configure | 4 ++-- gcc/configure.ac | 4 ++-- 5 files changed, 48 insertions(+), 8 deletions(-)