[PATCH] [lld] [ELF] Support for general dynamic TLS relocations on X86_64

[Shankar Easwaran]

On Fri, Sep 26, 2014 at 7:05 PM, kledzik at apple.com <kledzik at apple.com>
wrote:

> >  should we add a special case to the reader to convert them to weak
> undefines?
> That is what I was thinking.  But you should investigate how this works
> with the gnu linker.  Does the linker really hard code "__tls_get_addr" to
> be special?  Or does it always implicitly link with ld.so?
>
> The gnu linker doesnot implicitly link with ld.so, the clang/gcc driver
passes the path to the dynamic linker as part of the command line.

The linker processes the dynamic linker as a regular input file.


> >canBeNullAtBuildTime is associated with a weak symbol while
> __tls_get_addr is not a weak symbo in the writer, which changes the symbol
> semantics.
> I'm not sure what you are saying here.  If "__tls_get_adder" was a weak
> *undefined* symbol in the .o file, everything would work correctly. Static
> linking ignores the canBeNullAtBuildTime aspect of UndefinedAtoms, so
> either it is defined in an archive, or you get a linker error.  For dynamic
> executables, if it "__tls_get_adder"  not defined anywhere, the linker
> notices the

canBeNullAtBuildTime and conjures up a SharedLibraryAtom for it.
>
> When the compiler generates position independent code, the PIC code always
generates __tls_get_addr as a normal undefined symbol.

Until we dont start optimizing tls accesses (Global dynamic to Initial
executable), there should not be a need in the linker to create this symbol
and resolve the symbol against what the linker implicitly defined.


http://reviews.llvm.org/D5505
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140927/bfe1b37e/attachment.html>