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

[Rafael Auler]

I initially thought that it was this way too, when I made this patch. Then
I updated my patch because I found evidence that the correct way is as
Shankar says, at least in my system. Please correct me if this happens
differently in any other ELF system, because then, we need to explictly
define the __tls_get_addr atom, but I believe that we don't need. I quickly
scanned though binutils source code and found no evidence that
__tls_get_addr was being special cased.

In my x86_64 gnu linux system, it goes like this: (I tested in a 32bit
system and I got similar results)

# inputs
$ echo '__thread int mytlsnum = 0; int getnum() { return mytlsnum; }' >
tlslib.c
$ echo 'int getnum(); int main() { return getnum(); }'> main.c

# create objects and lib
$ clang -fPIC -c tlslib.c -o tlslib.o
$ ld -shared tlslib.o -o libtest.so
$ clang -c main.c -o main.o

# create executable -- in this example, this is where __tls_get_addr needs
to
# be resolved because we didn't link against ld.so when creating libtest.so,
# so this symbol is still undefined with no clue where it is defined.
# This is where clang will link against the dynamic linker itself as a
regular input:
$ clang main.o -L. -ltest -o hello -###
(...)
"/usr/bin/ld" "-z" "-relro" ....
"-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu" -lc

Now, if you inspect
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.so, it is
a linker script that says:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc_nonshared.a  AS_NEEDED (
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )


See that it is explictly requesting to link against the dynamic linker
itself at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2, which defines
__tls_get_addr.



On Sun, Sep 28, 2014 at 6:11 AM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Sat, Sep 27, 2014 at 06:14:25PM -0700, Shankar Easwaran wrote:
> > The linker processes the dynamic linker as a regular input file.
>
> Huh? The dynamic linker is just a path going into the binary, it should
> not be opened at all. It might not even exist at time of linking.
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140928/c3edd712/attachment.html>