This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
* H. J. Lu:
> The GCC driver patch has been checked into GCC 8. Here is the updated
> patch for glibc.
>
> Tested with build-many-glibcs.py. Any objections?
Is the entire text below supposed to go into the commit message? What
about the remaining tasks listed in it?
> Dynamic linker, ld.so, is a standalone program which can be loaded at
> any address. This patch adds a configure option, --enable-static-pie,
> to embed the part of ld.so in static executable to create static position
> independent executable (static PIE). A static PIE is similar to static
> executable, but can be loaded at any address without help from a dynamic
> linker. When --enable-static-pie is used to configure glibc, libc.a is
> built as PIE and all static executables, including tests, are built as
> static PIE. The resulting libc.a can be used together with GCC 8 or
> above to build static PIE with the compiler option, -static-pie. But
> GCC 8 isn't required to build glibc with --enable-static-pie. When an
> older GCC is used to build glibc with --enable-static-pie, proper input
> files are passed to linker to create static executables as static PIE,
> together with "-z text" to prevent dynamic relocations in read-only
> segments, which are allowed in static PIE.
The last sentence is unclear. Is -z text required to use a glibc
compiled by an earlier GCC? What exactly is the problem with dynamic
relocations in read-only segments? Are they allowed or disallowed?
Can we support .data.relro?
> Static PIE can work on all architectures which support PIE, provided:
>
> 1. Target must support accessing of local functions without dynamic
> relocations, which is needed in start.S to call __libc_start_main with
> function addresses of __libc_csu_init, __libc_csu_fini and main.
Are there really ABI concerns for the statically linked case? It
should not be necessary to pass these function pointers.
> All functions in statice PIE are local functions. If PIE start.S
> can't
Typo: “statice”
> 6. __brk works without TLS nor dynamic relocations in read-only section
> so that it can be used by __libc_setup_tls to initializes TLS in static
> PIE.
Note that some kernels have strange address space layouts which
prevent __brk from working reliably.
> NB: When glibc is built with GCC defaulted to PIE, libc.a is compiled
> with -fPIE, regardless if --enable-static-pie is used to configure glibc.
> When glibc is configured with --enable-static-pie, libc.a is compiled
> with -fPIE, regardless wether GCC defaults to PIE or not. The same libc.a
> can be used to build both static executable and static PIE. There is no
> need for separate PIE copy of libc.a.
Is there a code size cost to PIE?
> Linker requirements to build glibc with --enable-static-pie:
>
> 1. Linker supports --no-dynamic-linker to remove PT_INTERP segment from
> static PIE.
> 2. Linker can create working static PIE. The x86-64 linker needs the
> fix for
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21782
So binutils 2.29 is the minimum requirement on x86-64?
Can an earlier binutils version be used to build a static library
which is usable for PIE with binutils 2.29+?
> +'--enable-static-pie'
> + Build static executables, including tests, as position independent
> + executable (static PIE) which is similar to static executable, but
> + can be loaded at any address without help from a dynamic linker.
> + The resulting libc.a can be used with the GCC option, -static-pie,
> + which is available with GCC 8 or above, to create static PIE. Only
> + i686, x86-64 and x32 targets are verified to work.
Drop the last sentence, it will be outdated soon.
> diff --git a/Makeconfig b/Makeconfig
The reason for some of the changes are not obvious at all to me, and
the ChangeLog doesn't give an explanation either.
> new file mode 100644
> index 0000000000..aa9302602b
> --- /dev/null
> +++ b/elf/dl-reloc-static-pie.c
Is there anything which inhibits compilation of this file ith the
stack protector? I think this is necessary because
_dl_relocate_static_pie is called so early.
> +extern struct link_map * _dl_get_dl_main_map (void)
> + __attribute__ ((visibility ("hidden")));
This should go into a header file somewhere, so that the declaration
can be checked against the definition.
> diff --git a/elf/dl-support.c b/elf/dl-support.c
> index 235d3a7f46..b9fc1a66fe 100644
> --- a/elf/dl-support.c
> +++ b/elf/dl-support.c
> @@ -385,3 +385,14 @@ _dl_non_dynamic_init (void)
> #ifdef DL_SYSINFO_IMPLEMENTATION
> DL_SYSINFO_IMPLEMENTATION
> #endif
> +
> +#if ENABLE_STATIC_PIE
> +/* Since relocation to hidden _dl_main_map causes relocation overflow on
> + aarch64, a function is used to get the address of _dl_main_map. */
> +
> +struct link_map *
> +_dl_get_dl_main_map (void)
> +{
> + return &_dl_main_map;
> +}
> +#endif
Is this issue really aarch64-specific, or could it affect other
targets?