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

[Xinliang David Li via llvm-commits]

On Sat, May 7, 2016 at 12:40 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sat, May 07, 2016 at 11:52:25AM -0700, Xinliang David Li via
> llvm-commits wrote:
> > On Sat, May 7, 2016 at 11:45 AM, Joerg Sonnenberger <joerg at netbsd.org>
> > wrote:
> >
> > > joerg added a comment.
> > >
> > > In http://reviews.llvm.org/D19995#424195, @davidxl wrote:
> > >
> > > > Also note this is not something new introduced by this patch. Non-pie
> > > case
> > > >  already does it.
> > >
> > >
> > > One reason a  lot of OS people are pushing for PIE is to get rid of
> copy
> > > relocations.
> >
> >
> > Do you mean that the reason people using PIE is to avoid copy relocs or
> > something else?  Also any references to your claim?
>
> It is certainly one motivation for moving towards PIE, yes.
>

why? Will -fpic -pie work in this case to avoid using copy relocs?


>
> > > Again, please do not add another instance of them. The behavior can be
> > > obtained without any such regressions.
> > >
> >
> > except that some may consider this progression, not regression.   This
> new
> > behavior is also controllable with an option. The default setting is
> > subject to debate.
>
> Well, it certainly fits:
> https://devhumor.com/content/uploads//images/July2015/bug-vs-feature.jpg
>
> Seriously, you haven't even demonstrated that it provides an actual
> performance benefit. If you want to do something useful, help making
> protected usable. Copy relocations should be buried as mistake of the
> past.
>

There are certainly performance gains from this. If you don't believe it,
you can try turn of copyreloc for non-pie builds to see what will be
affected. This is one of the main cause of slow down when PIE is turned on
for security hardening -- YMMV, but we've seen up to 4% IIRC.

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/20160507/30bc999c/attachment.html>