Re: [patch ob] Disallow -pie and -static

[Mike Frysinger <vapier at gentoo dot org>]

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

Attachment: signature.asc
Description: This is a digitally signed message part.