RFC: TLS improvements for IA32 and AMD64/EM64T

[Alexandre Oliva]

On Feb  6, 2006, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Sep 22, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Sep 17, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Sep 16, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>> On Sep 16, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>>> Over the past few months, I've been working on porting to IA32 and
>>>>> AMD64/EM64T the interesting bits of the TLS design I came up with for
>>>>> FR-V, achieving some impressive speedups along with slight code size
>>>>> reductions in the most common cases.

>>>>> Although the design is not set in stone yet, it's fully implemented
>>>>> and functional with patches I'm about to post for binutils, gcc and
>>>>> glibc mainline, as follow-ups to this message, except that the GCC
>>>>> patch will go to gcc-patches, as expected.

>>>> This is the glibc portion of the implementation.  I've built it for
>>>> amd64-linux-gnu and i686-pc-linux-gnu, with both the current TLS
>>>> dialect and the new -mtls-dialect=gnu2, without regressions.

>>> Revised patch using new relocation and dynamic entry numbers.  Tested
>>> again on all 4 combinations mentioned above.

>> Revised patch that does not include other changes, fixes a few
>> inconsistent uses of addends here and there (copy&pastos), avoids
>> crashing when lazily resolving TLSDESC relocations to weak symbols
>> that turn out to be undefined, and, as a bonus, handles them correctly
>> such that their address does map to NULL for all threads.  I know
>> people shouldn't rely on this, since the linker may very well break
>> it, but hey, since I was already tweaking the code to avoid crashes,
>> why not take the final step and make it work as closely as possible to
>> a random person's expectations? :-)

Updated and re-tested with Sunday's glibc tree, using GCC 4.1.2
20060920 with a backport of the TLS descriptor patch and
binutils-2.17.50.0.3-6 as in Fedora rawhide.

There is one new test failure, that has to do with an assumption in
elf/tst-tls-dlinfo.c that no longer holds after the change: we will
try to allocate the TLS block for a dlopened module in the static TLS
block, because it's faster, even if doing so wouldn't be necessary.
Therefore the test that RTLD_DI_TLS_DATA is NULL before a TLS variable
in that module is first used fails.

There are two ways to fix that: make the test lenient to this change
in behavior, or expand the TLS segment in the dlopened module such
that it won't fit in the static TLS block, and will thus be assigned
to dynamic TLS.  Which one should I take?

This reminds me that, given this new trait of trying to fit even
dynamically-loaded modules in the static TLS block, it might make
sense to introduce support for a LD_ environment variable to determine
how much extra space should be reserved in the static TLS block for
dlopened modules.

The patch is broken up in two pieces, one that adds TRY_STATIC_TLS in
machine-independent code, and one that only touches machine-specific
code (mainly systeps, but also the new relocations in elf.h).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlsdesc-try-static.patch
Type: text/x-patch
Size: 2903 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20061010/55cd19f1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlsdesc-2.patch
Type: text/x-patch
Size: 72815 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20061010/55cd19f1/attachment-0001.bin>
-------------- next part --------------

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}