<div dir="ltr"><div>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.</div><div><br></div><div>In my x86_64 gnu linux system, it goes like this: (I tested in a 32bit system and I got similar results)<br></div><div><br></div><div># inputs</div><div>$ echo '__thread int mytlsnum = 0; int getnum() { return mytlsnum; }' > tlslib.c</div><div>$ echo 'int getnum(); int main() { return getnum(); }'> main.c</div><div><br></div><div># create objects and lib</div><div>$ clang -fPIC -c tlslib.c -o tlslib.o</div><div>$ ld -shared tlslib.o -o libtest.so</div><div>$ clang -c main.c -o main.o</div><div><br></div><div># create executable -- in this example, this is where __tls_get_addr needs to</div><div># be resolved because we didn't link against ld.so when creating libtest.so,</div><div># so this symbol is still undefined with no clue where it is defined.</div><div># This is where clang will link against the dynamic linker itself as a regular input:</div><div>$ clang main.o -L. -ltest -o hello -###</div><div>(...)</div><div>"/usr/bin/ld" "-z" "-relro" .... "-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu" -lc</div><div><br></div><div>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:</div><div><br></div><div><div>/* GNU ld script</div><div>   Use the shared library, but some functions are only in</div><div>   the static library, so try that secondarily.  */</div><div>OUTPUT_FORMAT(elf64-x86-64)</div><div>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 ) )</div></div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 28, 2014 at 6:11 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Sep 27, 2014 at 06:14:25PM -0700, Shankar Easwaran wrote:<br>
> The linker processes the dynamic linker as a regular input file.<br>
<br>
</span>Huh? The dynamic linker is just a path going into the binary, it should<br>
not be opened at all. It might not even exist at time of linking.<br>
<br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div>