[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Sun May 8 14:10:55 PDT 2016


On Sun, May 8, 2016 at 7:46 AM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sat, May 07, 2016 at 05:39:15PM -0700, Xinliang David Li wrote:
> > On Sat, May 7, 2016 at 11:52 AM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > On Sat, May 07, 2016 at 10:58:51AM -0700, Xinliang David Li via
> > > llvm-commits wrote:
> > > > To be clear, assuming copyrelocs (support in linker) allows compiler
> to
> > > > generate efficient code (speculatively) to access external globals
> which
> > > > compiler has no idea where they are going to be defined. For most of
> the
> > > > cases, the most of globals end up in the main program, so copyrelocs
> is
> > > > only a fallback mechanism in case that is not the case.
> > >
> > > I think your reasoning is confusing cause and effect. Copy relocations
> > > exist, because people didn't want to change things when shared linkage
> > > was introduced.
> >
> >
> > What do you mean by 'people didn't want to change things'?
>
> Exactly what I wrote. Static linkage was the default, then patching with
> XCOFF. ELF's mechanism are late to the game. Copy relocations are a
> result of wanting to mix non-position independent main binaries with
> shared libraries.
>
> > For executable, copy reloc is introduced so that global access without
> GOT
> > can be used without requiring text relocation when the reference is truly
> > external.  Are you saying this is not the case?  History aside, this is
> > certainly how copyreloc is used today.
>
> Code generated without -fPIC on most architectures doesn't use the GOT.
> That means the link editor has to be patch things up as best as it can
> to make it use shared libraries. Two direct results from this are:
> (1) Variables defined in shared objects must be relocated to the main
> binary, when referenced from this.
> (2) The identify of functions is the PLT slot of the main binary, when
> referenced.
>
> Both issues have a long history of creating compatibility and
> performance issues.
>

Let's keep the discussion on topic -- we are not discussing how shared
linkage should be handled vs what is available today.


>
> > > It is a horrible hack and everyone seriously involved
> > > with ELF acknowledges that it is a horrible hack only comparible to
> text
> > > relocatiions
> >
> >
> > You can certainly feel this way, but making claims about 'everyone
> involved
> > ..' seems to have no basis and is not relevant here.
>
> I don't see anyone disagreeing... I'm still surprised that binutils is
> willing to restore this crap, but given their history of I shouldn't be.
>

The above statement is contradicting itself.


> I would certainly hope that Rui et al have a difference stance on repeat
> the mistakes of the past here.


Do you mean let lld to not support copyreloc? How do you expect this to
work with non-PIE executable (linked with shared libs)? Or do you expect
compiler also to change in this direction?



> If you want to see a good example of why
> copy relocations are bad, look for the recent "libc++'s cout getting
> aligned differently" bug in clang. That's a wonderful example of the
> kind of issues copy relocations and where they hurt performance much
> more than any advantage they ever produce.
>

It is certainly possible to come up with a scenario that copyrelocs can
hurt performance. For instance, shared lib has lots of hot globals that are
properly laid out (manually or via PGO). Using copyreloc can make it work.
However this is mostly an implementation quality issue. It is also *not*
general as you claimed.   On the other hand, the link time optimizer can
actually take advantage this to enable optimal data layout across shared
library boundaries, but this is slightly off-topic.


> So let me repeat: if you want to get the performance benefits of
> non-interposable references, work on making protected actually usable.

This includes the more important dllimport side. That's useful not just
> for the special case of the main binary, but can be used for shared
> libraries as well. It is something where code in the wild is already
> known to exploit the lack of copy relocations for PIE. Do not add copy
> relocations back.
>

It seems to me the main motivation of your objection is that there is
 dependence on the current implementation specific behavior of PIE (not
using copyreloc) which is not reasonable. Do not rely on something that is
not specified.

It is true that copyreloc is not perfect and has  its own limitations and
problems, but do not deny its benefits because you do not like it. If you
feel really strongly about this, I think you should propose alternatives
and make it generally accepted as well standard.  (So far It is not even
clear to me what your proposal is: asking user to change source to annotate
with protected visibility? making all linkers to automatic rewrite (without
additional overhead, size/icache etc)? or something else? )  When the
alternative is ready, we can talk about getting rid of copyreloc (even for
non-PIE usage).


thanks,

David

>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160508/f76a2ba2/attachment.html>


More information about the llvm-commits mailing list