[Bug other/67812] New: Default-PIE patch broke building compiler as PIE and on esp toolchains

[Bug other/67812] New: Default-PIE patch broke building compiler as PIE and on esp toolchains

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67812

            Bug ID: 67812
           Summary: Default-PIE patch broke building compiler as PIE and
                    on esp toolchains
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

The default-pie patch added the following to gcc/Makefile.in:

+# We don't want to compile the compilers with -fPIE, it make PCH fail.
+COMPILER += @NO_PIE_CFLAGS@
+
+# Link with -no-pie since we compile the compiler with -fno-PIE.
+LINKER += @NO_PIE_FLAG@

This precludes building the compiler as PIE, which leads to multiple problems:

1. On existing PIE-by-default toolchains (ESP patches), -fno-PIE gets added to
NO_PIE_CFLAGS, but NO_PIE_FLAG remains blank, because the negative option was
called -nopie rather than -no-pie. Using -fno-PIE without -no-pie/-nopie
results in link errors on some host archs.

2. Refusal to build as PIE may violate distro policy of shipping only PIE
binaries.

3. For nommu systems, building as PIE is mandatory; non-PIE binaries simply
cannot run.

If there's an issue where PCH does not work with PIE then PCH should just be
disabled when the compiler is built as PIE. This worked fine before, and is
completely orthogonal to whether the compiler produces PIE by default; one is a
host issue and the other is a target issue.

[Bug other/67812] Default-PIE patch broke building compiler as PIE and on esp toolchains

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67812

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>3. For nommu systems, building as PIE is mandatory; non-PIE binaries simply cannot run.


Those won't work as GCC hosts anyways.

>2. Refusal to build as PIE may violate distro policy of shipping only PIE binaries.

Sorry but PIE can't be used for GCC.  If a distro policy of shipping only PIE
binaries then don't ship the compiler as the compiler is a security hole in
itself :).

[Bug other/67812] Default-PIE patch broke building compiler as PIE and on esp toolchains

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67812

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
It's always worked fine in the past; I'm running GCC built as PIE on all my
systems. Presumably distros will just patch this out, but it would be nice to
get it fixed upstream.

As for nommu, I'm pretty sure GCC can run on nommu host; actually we're about
to test this on J2.

[Bug other/67812] Default-PIE patch broke building compiler as PIE and on esp toolchains

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67812

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
Further research into the PCH issue shows that it will be seriously broken when
GCC is built as PIE; this looks hard to fix, but worthwhile to fix if it can
be. There's almost certainly no way it can work on FDPIC hosts, even when run
with MMU where the default load address gets used, since function descriptors
may be dynamically allocated and their addresses could vary according to ASLR.

In the mean time, would it be acceptable to just make PCH support depend on
#ifndef __PIC__? Even if the build system turns off (or attempts to turn off)
PIE like it's doing now, having #ifndef __PIC__ around the PCH code would be a
good fail-safe against random code execution if GCC somehow gets built as PIE
anyway. And users who really want/need PIE could just drop the Makefile.in
lines above and have everything work.