[patch ob] Disallow -pie and -static
Mike Frysinger
vapier@gentoo.org
Mon Feb 27 19:49:00 GMT 2012
On Monday 27 February 2012 14:01:37 Ian Lance Taylor wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On Monday 27 February 2012 12:41:22 Ian Lance Taylor wrote:
> >> Mike Frysinger writes:
> >> > On Tuesday 14 February 2012 19:48:43 Cary Coutant wrote:
> >> >> I'm committing this patch under the trivial and obvious rule. If -pie
> >> >> and -static are both given together, gold will currently issue an
> >> >> internal error.
> >> >
> >> > shouldn't there be a bug to fix this then ? there's no technical
> >> > reason for disallowing static pie's from the perspective of the
> >> > linker ...
> >>
> >> On GNU/Linux a PIE is just an executable shared library. How would you
> >> implement a statically linked PIE?
> >
> > from what perspective ? if i build all my code with -fPIE (including
> > libc.a and friends), then link with -static -pie, i should have an ELF
> > that doesn't need shared libraries nor runtime ldso and can be run from
> > any address.
>
> But linking with -pie really just generates a shared library. And a
> shared library requires ld.so. So I don't understand what you would
> generate.
my point was from the perspective of the linker, it should not care. from the
perspective of glibc, there is work to be done.
> > conceptually, i don't see why static PIE is anything special from static
> > non- PIE. maybe i'm missing something fundamental.
>
> In order to implement any sort of PIE something needs to do runtime
> relocation of all absolute references. In a statically linked
> executable, what is going to do that?
>
> It is not impossible to generate a statically linked PIE, but it
> requires support from the startup files and libraries which does not
> currently exist on GNU/Linux systems. If somebody wrote that support,
> and defined what the linker had to do to invoke it, then it would make
> sense for the linker to support -static -pie. Until then, it is better
> for the linker to give an error.
yes, the startup objects would take care of the bootstrap. FDPIC ports
certainly do this already since PIC/PIE is the only thing they can support.
my point was just that saying, from the perspective of the linker, "-pie and -
static are incompatible" is wrong. you could phrase it "-pie and -static are
not currently supported". further, i'm not sure if the issue was looked at
beyond "we got an internal error with -static -pie, so disallow the flag combo"
vs "gold assumes XXX and rather than adjust that assumption which would take a
bit of work, disallow the flags". the e-mail summary is light on details.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20120227/87318988/attachment.sig>
More information about the Binutils
mailing list