Problem with LD-to-LE relaxation in gnu2 tls-dialect (IA32 and X86-64)

[Alexandre Oliva]

On Jun 19, 2008, "Cary Coutant" <ccoutant@google.com> wrote:

> Here's a test case for the problem I was talking to you about...

Thanks for your report.

So, basically the problem was that, when relaxing Local Dynamic to
Local Exec, when linking an executable, we set up the base address as
the lowest address of the executable's TLS Block (_TLS_MODULE_BASE_),
and then added to it the NTPOFF of the variables (relaxed from
DTPOFF), which by itself would have been enough to get to the variable
addresses starting from the Thread Pointer.  Oops.

Thanks for pointing this out.  I'd missed this even when writing the
linker testcases.  So much for writing testcases to the spec rather
than for expected behavior :-(

> In gold, I set _TLS_MODULE_BASE_ properly, and this example works.

> I tried this simple patch in bfd/elf32-i386.c:

>  	  if (!(_bfd_generic_link_add_one_symbol
>  		(info, output_bfd, "_TLS_MODULE_BASE_", BSF_LOCAL,
> -		 tls_sec, 0, NULL, FALSE,
> +		 tls_sec, tls_sec->size, NULL, FALSE,
bed-> collect, &bh)))

> But it looks like tls_sec->size is still zero at this point, so it
> didn't help. I can look into this further and submit a patch if you
> like. I'll also submit a bug report if you agree with my analysis of
> the problem.

AFAICT, gold will actually work in main executables, but break in
dynamic libraries, because there _TLS_MODULE_BASE_ *is* supposed to be
the lowest address.  I haven't got as far as as building gold to
verify what I grasped from the code (or to fix it, for that matter),
but I did verify that LD worked in dynamic libraries before the patch
with the old ld, it was broken only for main executables.  So, unless
I misunderstood something, gold will need some fixing as well.  Try to
compile the attached source file (slightly modified from the one you
sent me) as below (assuming your gcc will use gold as the linker) and
you'll see.

gcc -O2 -mtls-dialect=gnu2 tls.c -DTEST -fpic -shared -o libtls.so
gcc -O2 -mtls-dialect=gnu2 tls.c -DMAIN libtls.so -o tls-lib -Wl,-R.
gcc -O2 -mtls-dialect=gnu2 tls.c -o tls-dyn
gcc -O2 -mtls-dialect=gnu2 tls.c -static -o tls-stt

./tls-lib
./tls-dyn
./tls-stt

With the patch below (after the test file), using the old linker, both
-m32 and -m64, all 3 tests ran successfully for me, and the linker
i386 and x86-64 fixed testsuites passed, on an x86_64-linux-gnu native
build.  Ok to install?

FWIW, I've also amended the ABI extension RFC so as to note this
situation and specify the expected outcome.  The updated version is
available at the following URL:
http://people.redhat.com/aoliva/writeups/TLS/RFC-TLSDESC-x86.txt

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tls.c
URL: <https://sourceware.org/pipermail/binutils/attachments/20080704/df3f7e68/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tls-x86-LD2LE.patch
Type: text/x-patch
Size: 8265 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20080704/df3f7e68/attachment.bin>
-------------- next part --------------

-- 
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}