This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Adding static-PIE support to binutils
- From: Rich Felker <dalias at libc dot org>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 19 Aug 2015 00:14:36 -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> <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> <CAMe9rOorDaT1YEf=FrGMnyZgOmAGwrBpTEMZtYROCXG=ioSLvQ at mail dot gmail dot com> <20150819005842 dot GN32742 at brightrain dot aerifal dot cx> <20150819040011 dot GE20393 at bubble dot grove dot modra dot org>
On Wed, Aug 19, 2015 at 01:30:12PM +0930, Alan Modra wrote:
> On Tue, Aug 18, 2015 at 08:58:43PM -0400, Rich Felker wrote:
> > 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.
>
> This is OK to commit with a suitable ChangeLog. I think a separate ld
> option is best too, because historically -static and its aliases
> -Bstatic, -dn, -non_shared really are about what type of libraries are
> accepted rather than choosing linker output type.
I see good arguments for both ways, and H.J. Lu seems to have switched
sides midway if I understand correctly. Using the existing -static
option seems nice in that it avoids the need for GCC to know whether
ld supports --no-dynamic-linker, but GCC needs to know the right crt
file to link anyway. And linking the rcrt1.o file with self-relocation
code would be wrong if an external dynamic linker were used. So I
don't think this really simplifies the GCC-side problem at all.
On the other hand, having a dedicated option also makes other neat
stuff possible: for instance, it's possible to do dynamic linking, but
with the dynamic linker itself (or at least the bootstrap part of it)
linked into the application. This is a potentially interesting setup
when you don't want to depend on a fixed dynamic-linker path; the
program could instead to an rpath-$ORIGIN style search for its dynamic
linker and libs. I don't have any plans to implement such a thing
right now, but it's nice to have the option to do so. Overloading
-static would not allow this, or at least not easily, since it would
suppress linking shared libraries unless you tweak the order
perfectly.
So, my mild preference is to stick with the way I've done it in the
patch, using --no-dynamic-linker (or a different name if anyone wants
to change the name).
Rich