[lld] r295632 - Add more comments about copy relocations.

[Rafael Avila de Espindola via llvm-commits]

Rui Ueyama <ruiu at google.com> writes:

> On Tue, Feb 21, 2017 at 9:19 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> Joerg Sonnenberger via llvm-commits <llvm-commits at lists.llvm.org>
>> writes:
>>
>> > On Mon, Feb 20, 2017 at 06:16:08PM -0800, Rui Ueyama via llvm-commits
>> wrote:
>> >> Are you suggesting I bring it up to the LLVM blog? This comment is my
>> >> opinion, and I guess not everybody agrees we should avoid exporting
>> globals
>> >> from DSOs.
>> >
>> > Sadly, the accessor approach is expensive and often not a choice. A
>> > better way would be to provide an attribute to force GOT-based access
>> > even in non-PIC mode. We are slowly getting the necessary relocations on
>> > the modern platforms at least.
>>
>> I have adding a -fno-copy-reloc to clang in my todo list. But a library
>> author should at least document that copy relocations are not guaranteed
>> to work after an upgrade.
>>
>
> How does that -fno-copy-reloc option work?

It a lot of work, but basically we need to

* Make sure shouldAssumeDSOLocal is used everywhere.
* Make that bit explicit in the IR (I.E.: resurrect D20217)
* Have clang not set it if given -fno-copy-reloc.

The net result is that a reference to a symbol clang/llvm knows is local
will be direct. A reference to a symbol it can't be sure will use
got/plt.

Cheers,
Rafael