Re: i386 and x86_64 TLSDESC relocations to local symbols broken in gold

["Cary Coutant" <ccoutant at google dot com>]

Thanks for looking at this. Except for a typo (s/This is currently not
support/This is currently not supported/), your patch looks good to
me. I'll take a look at the other two problems -- I've been meaning to
get back to it ever since we talked at the summit, but it's been low
priority since we're still using a glibc and ld.so without gnu2
support.

-cary


2008/9/11 Alexandre Oliva <aoliva@redhat.com>:
> Hi,
>
> I finally got 'round to investigating how _TLS_MODULE_BASE_ could
> possibly be working on gold, since it hadn't been fixed along the
> lines of the fix that I installed in bfd on 2008-07-28.  Turns out it
> doesn't, and it's even more broken than I'd expected.
>
> I found out it generates bad TLSDESC relocations in dynamic libraries,
> referencing local symbols.  The relocations that used to refer to
> local symbols are adjusted to refer to .tdata or .tbss symbols, but
> this doesn't work: the value of these section symbols is not an offset
> into the TLS segment like regular TLS symbols, but rather an absolute
> offset within the executable, so the computations are all way off.
>
> BFD generates an *ABS*+<dtpoff> relocation for these cases, as
> expected.  I guess I should mention this in the specs...  Ideally,
> libc run-time should be able to cope with section symbols, but it
> doesn't, and I'm not sure how easy it would be to add this.
>
> Furthermore, symbols that are not at offset zero in their sections are
> getting what should have been the addend of the relocation in place at
> the GOT entry, rather than in the addend field of the relocation, as
> expected for a RELA relocation.  I'm pretty sure this will cause the
> addend to be completely disregarded at run-time, even if the other
> problems above are fixed.
>
> FTR, all tls*gnu2* testcases in the gold testsuite pass when the
> bfd-based linker is used to link them, but tls_shared_gnu2_test fails
> because of errors WRT local variables.
>
> Anyhow, here's the patch that fixes the first of the 3 problems.  I'm
> not sure when I'm going to be able to get back to the other two;
> pretty please beat me to it :-)
>
>
>
> --
> Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
> Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
> FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
> Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
>
>