[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 Sun, May 8, 2016 at 2:19 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sun, May 08, 2016 at 02:10:55PM -0700, Xinliang David Li wrote:
> > 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).
>
> It is clear to me that any further discussion is pointless as you don't
> want to accept that copy relocations are a horrible idea.



Do not expect people to agree with you because of the strong words used
throughout the discussions: horrible, everyone dislikes etc.



> It is also
> clear that you do not even want to look at the *existing* alternatives.
>

Wrong assertion. If we can get back to technical discussions without
resorting to attacking, that will be great.  You can lay down your
proposals in more details and compare pros/cons of different alternatives.
We need a solution that is generally good and easy for users (including the
lazy programmers you referred ) to use.  Also what are the main pain points
of copyreloc to you? slower startup time or something else?

thanks,

David



> My objection stands: do not add copy relocations for a code path that
> never used or needed them before. It is not a question of "get rid of
> them later". The long history of ELF has proven one thing beyond doubt:
> if a feature has introduced once, it is extremely difficult to get rid
> of it later, even and especially if it is broken. "But it is optional"
> hasn't worked for the mess of DT_RPATH vs DT_RUNPATH either.
>
> 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/8f43465e/attachment.html>