This is the mail archive of the
mailing list for the binutils project.
Re: Adding static-PIE support to binutils
- From: Rich Felker <dalias at libc dot org>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>, gcc at gcc dot gnu dot org
- Date: Tue, 18 Aug 2015 11:25:18 -0400
- Subject: Re: Adding static-PIE support to binutils
- Authentication-results: sourceware.org; auth=none
- References: <20150624041847 dot GA26414 at brightrain dot aerifal dot cx> <CAJimCsG1chOud0ZRHOcnY6XN08XGiwqfsrVYN=MFMRyO4+0cjA at mail dot gmail dot com>
On Mon, Aug 17, 2015 at 10:29:41PM -0700, Cary Coutant wrote:
> > 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.
> For the uses you have in mind, -static and -pie together make perfect
> sense, but I'd argue that the output file in that case ought to be
> ET_EXEC, since it will be in fact a standalone binary to be loaded
> directly by the kernel. Not only would you want to omit the .interp
> section (actually the PT_INTERP segment), but you also have no need
> for the PT_DYNAMIC segment (.dynamic section).
As far as I can tell, on the kernel side ET_EXEC implies MAP_FIXED.
Use of ET_EXEC vs ET_DYN is a separate matter from whether or not
PT_DYNAMIC exists. Non-PIE dynamic-linked main executables with type
ET_EXEC have PT_DYNAMIC, for example.
> The only thing you need over a standard ET_EXEC file is the dynamic
> relocations, with linker-generated symbols bracketing the start and
> end of the relocations so that your custom startup code can find them.
> It should be reasonably easy to arrange for these.
Yes but it's much easier to use _DYNAMIC, and this is also more
compatible with existing tools. I suspect gdb would have trouble if
_DYNAMIC were missing, though I haven't checked. There's also the
matter of arch-specific mess in _DYNAMIC (e.g. the wacky MIPS
'compacted' relocation table for the GOT) that would be a lot of
arch-specific work to reimplement with an alternate scheme.
bFLT already played the game of "let's redo relocation information in
an ad-hoc way instead of using existing ELF mechanisms" and it was an
utter mess; I don't want to go down that road again.