On Fri, 6 Mar 2015, H.J. Lu wrote:
> +# We don't want to compile the compiler 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@
As I understand it, what we don't want is the compiler to be a PIE. That
is, it must be linked -no-pie (and given that the compiler is not a PIE,
compiling -fPIE would be pointless, although it wouldn't actually break
things to have PIE objects in the compiler as long as it's linked for a
fixed address).
> +#if defined ENABLE_DEFAULT_PIE
> +#define GNU_USER_TARGET_STARTFILE_SPEC \
> + "%{!shared: %{pg|p|profile:gcrt1.o%s;: \
> + %{" PIE_SPEC ":Scrt1.o%s} %{" NO_PIE_SPEC ":crt1.o%s}}} \
> + crti.o%s %{static:crtbeginT.o%s;: %{shared:crtbeginS.o%s} \
> + %{" PIE_SPEC ":crtbeginS.o%s} \
> + %{" NO_PIE_SPEC ":crtbegin.o%s}}" \
> + FVTABLE_VERIFY_SPEC
> +#else
> +#define GNU_USER_TARGET_STARTFILE_SPEC \
> + "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
> + crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}" \
> + FVTABLE_VERIFY_SPEC
> +#endif
With appropriate definitions of PIE_SPEC and NO_PIE_SPEC, shouldn't a
single definition of GNU_USER_TARGET_STARTFILE_SPEC be able to work for
both ENABLE_DEFAULT_PIE and !ENABLE_DEFAULT_PIE?
<https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00393.html> noted a
possible issue with MIPS. Actually, rather more config/*.h and
config/*/*.h headers contain specs testing for (-fpie, -fPIE, -fno-pie,
-fno-PIE, -pie) options, which would be affected by these changes. I'd
say this patch should include an initial attempt at adjusting those config
headers, which should be an essentially mechanical change not requiring
understanding anything target-specific. For link-time specs, that may
mean using PIE_SPEC and NO_PIE_SPEC. For compile-time specs, similar new
macros would be added. Given such adjustments included in the patch and
the relevant target maintainers CC:ed, I might then be inclined to approve
the patch on the basis of allowing a week for target maintainers to test
the changes for their targets before commit, as I don't see any major
problems with it beyond the need to update the target-specific specs.
--
Joseph S. Myers
jos...@codesourcery.com
