This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Adding static-PIE support to binutils
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Binutils <binutils at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 18 Aug 2015 09:30:56 -0700
- Subject: Re: Adding static-PIE support to binutils
- Authentication-results: sourceware.org; auth=none
- References: <20150624041847 dot GA26414 at brightrain dot aerifal dot cx> <CAMe9rOoQCDXZK_LTCt81+WvtBLsnNbGDR10_aKe4s8D+-3Ehng at mail dot gmail dot com> <20150818024256 dot GF32742 at brightrain dot aerifal dot cx> <20150818034443 dot GH32742 at brightrain dot aerifal dot cx> <CAMe9rOqZmc9K_bEKqWZ6tkTE66OegyE0JMRef1xEf32hWCPPSg at mail dot gmail dot com> <20150818160855 dot GK32742 at brightrain dot aerifal dot cx>
On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker <dalias@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 <dalias@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 <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?
>> >
>> > 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.
--
H.J.