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

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

[Iain Sandoe]

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
+
 # 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])
 
-- 
2.24.3 (Apple Git-128)

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

[Richard Sandiford]

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])

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

[Iain Sandoe]

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])

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

[Richard Sandiford]

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

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

[Iain Sandoe]

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)

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

[H.J. Lu]

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)
>


-- 
H.J.

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

[H.J. Lu]

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.



-- 
H.J.

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

[Iain Sandoe]

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

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

[H.J. Lu]

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.

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

[Iain Sandoe]

> 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

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

[Richard Biener]

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
>
>
>