This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Problem with LD-to-LE relaxation in gnu2 tls-dialect (IA32 and X86-64)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Alexandre Oliva" <aoliva at redhat dot com>
- Cc: "Cary Coutant" <ccoutant at google dot com>, binutils at sourceware dot org
- Date: Thu, 3 Jul 2008 23:40:00 -0700
- Subject: Re: Problem with LD-to-LE relaxation in gnu2 tls-dialect (IA32 and X86-64)
- References: <c17be2b30806190829odf86d95n6b2cd406253bb004@mail.gmail.com> <ortzf6duvh.fsf@oliva.athome.lsd.ic.unicamp.br>
2008/7/3 Alexandre Oliva <aoliva@redhat.com>:
>> 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?
Is that possible to add some testcases?
> 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
>
Would you mind uploading it to
http://groups.google.com/group/ia32-abi
Thanks.
--
H.J.