This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding static-PIE support to binutils


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 <dalias@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?

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]