This is the mail archive of the
mailing list for the binutils project.
Adding static-PIE support to binutils
- From: Rich Felker <dalias at libc dot org>
- To: binutils at sourceware dot org
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 24 Jun 2015 00:18:47 -0400
- Subject: Adding static-PIE support to binutils
- Authentication-results: sourceware.org; auth=none
For background on the static PIE model I'm working with, see the
following post to the GCC list:
So far, I've been prototyping static PIE support by having GCC pass
the following options to ld instead of -static -pie:
-static -shared -Bsymbolic
This partly works, but since ld does not know it's producing a main
executable, it misses important details, including the ability to link
initial-exec and local-exec model TLS code correctly, as well as
various linking optimizations. So I think the right way forward is
making ld accept -static and -pie together to do the right thing.
In elflink.c, _bfd_elf_link_create_dynamic_sections assumes that
executables should always have a .interp section.
bfd_elf_size_dynamic_sections asserts this assumption again, and the
individual elf??-*.c files also do so in *_elf_size_dynamic_sections
where they set a default interpreter. (Is this even useful? Most of
the names are out of touch with reality, and GCC always passes an
explicit -dynamic-linker anyway, so I think this code should just be
Now I have a working prototype by changing the info->executable
condition to info->executable && info->dynamic, and having lexsup.c
store the value of input_flags.dynamic in link_info.dynamic after
processing the command line, but I'm not sure if this is the right
An alternative seems to be using a separate set of linker scripts to
throw away the .interp section when the output is static PIE. I tested
this a long time ago with some success (see
http://stackoverflow.com/a/10545163/379897 which shows a method) but
it seems like a hack.
Can anyone offer feedback on my approach and whether it would be
acceptable for upstream?