On Tue, Aug 18, 2015 at 5:58 PM, Rich Felker <dal...@libc.org> wrote: > On Tue, Aug 18, 2015 at 09:30:56AM -0700, H.J. Lu wrote: >> On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker <dal...@libc.org> wrote: >> > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote: >> >> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker <dal...@libc.org> wrote: >> >> > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> >> >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> >> >> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker <dal...@libc.org> wrote: >> >> >> > > 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. >> >> >> > >> >> >> > It is OK to use -static/-Bstatic/-non_shared with -shared and -pie. >> >> >> > I think you want --no-dynamic-linker. >> >> >> >> >> >> I see two overall approaches to making the option to omit .interp: >> >> >> >> >> >> 1. In elflink.c, make the creation of the .interp section conditional >> >> >> on a new field in link_info. >> >> >> >> >> >> 2. In ld code (ldlang.c? elf32.em?), check the command line option and >> >> >> remove the .interp section before it can be processed. >> >> >> >> >> >> I think option 1 is a lot cleaner, but it's also going to be a lot >> >> >> more invasive, because every single target arch (elf32-*.c and >> >> >> elf64-*.c) has its own ASSERT that the .interp section exists. These >> >> >> would also need to be updated to either check the new field in >> >> >> link_info, or to replace the ASSERT with a conditional. >> >> >> >> >> >> Before I spend a lot of time implementing one or the other, do you >> >> >> have any feelings on which way would be appropriate? >> >> > >> >> > I went ahead and did option 1 modulo all the target code except sh >> >> > which is where I'm testing it. My work-in-progress patch is attached. >> >> > This is obviously not ready to submit but I would appreciate any >> >> > feedback that's possible at this stage. >> >> >> >> + case OPTION_NO_DYNAMIC_LINKER: >> >> + command_line.interpreter = NULL; >> >> + link_info.nointerp = 1; >> >> >> >> No need to clear command_line.interpreter and please add a simple >> >> testcase to verify it works correctly. >> > >> > OK. Do I also need to update it to be against the new output_type >> > stuff you just committed? >> > >> >> That is a good idea. > > I've updated the patch to cover the changes needed for all the > elf??-*.c target files (lots of code duplication already there), skip > the clearing of command_line.interpreter, and based it on current git > master with your output_type changes. > > I haven't done a test case yet -- I looked briefly but couldn't find > documentation on how to add one. Is there a guide or template I should > look at? And do I need to open a BZ issue for the feature request, or > can non-bug changes like this skip BZ? >
I don't think a new command line option is needed. You add a new bit, nointerp_set: 1. For -static: if nointerp_set is 0; then nointerp = 1. 2. For -Bdynamic" nointerlp_set = 1. -- H.J.
