For background on the static PIE model I'm working with, see the following post to the GCC list:
https://gcc.gnu.org/ml/gcc/2015-06/msg00008.html 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 removed.) 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 approach. 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? Rich