On Thu, Apr 04, 2013 at 10:59:41AM +0200, Florian Weimer wrote:
> On 04/04/2013 10:42 AM, Jakub Jelinek wrote:
> >>I think a similar optimization would be possible for access to
> >>global variables because ld could compute the final layout of all
> >>global variables in the binary itself, just as in the non-PIE case.
> >
> >Nope. The thing is, depending on if the variable is known to bind locally
> >(for PIC that is essentially static or hidden visibility, for PIE you can
> >add to that global vars defined in the current CU), you either emit code
> >that avoids the indirection (say %rip addressing, GOTOFF etc.),
>
> Even in PIE mode, it is possible to bind all global variables
> locally. Even if the variable is defined in a DSO, we can allocate
> space for it in the main program and arrange for the GOT indirection
> in the DSO to point there. The DSO would use the indirection, but
> the main program wouldn't.
>
> It's slightly backwards, but isn't this how variables in DSOs are
> referenced from position-dependent code?
That requires copy relocations being used even for PIEs, so you'd need to
change the whole toolchain for that, and somehow deal with the new
dependencies (as in, PIE code with modified GCC would have to be linked
with a new linker, otherwise it wouldn't work).
Even if you do this, still PIE code won't be as fast as position dependent
code, but it will be closer to that. Of course, you'll still be unable to
prelink those, so the startup cost will be there in any case, so I hope you
aren't suggesting we build ls, grep, sh, thousands of little GUI apps, etc.
as PIE.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
