RFC: TLS improvements for IA32 and AMD64/EM64T

Alexandre Oliva aoliva@redhat.com
Sun Oct 8 20:53:00 GMT 2006

Hi, Evandro,

Sorry that it took so long for me to get back to you after the GCC
Summit.  I've been quite busy and couldn't focus on this issue for a

Here's an updated patch the should address all of your concerns.  The
proposed ABI changes haven't changed at all for almost a year, and in
the mean time we've ported it to one more platform (ARM), so I believe
this is rock solid now.

Let me know what you think about the proposed changes.  They document
what's implemented in GNU binutils, GCC and the pending patches I have
for glibc, that I'm retesting after updating them to a current tree.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlsdesc.patch
Type: text/x-patch
Size: 8137 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20061008/beccfbaa/attachment.bin>
-------------- next part --------------

On Sep 19, 2005, "Menezes, Evandro" <evandro.menezes@amd.com> wrote:

> Alexandre, 
>> Please read the document referenced in the patch, for 
>> starters.  In it you'll see the exact spelling of the coding 
>> samples is not final yet, and it doesn't make sense to 
>> maintain yet another copy of this until it settles down.  

> When it does, it'll be added to the ABI then.  Not before.  For now, it's OK to reserve the relocation numbers in this mailing list.  

>> Also, you'll find that the calculations are not quite 
>> possible to express in the way other relocations are 
>> expressed; suggestions are welcome.  

> State so, perhaps in a note, expanding what they mean.

>> Finally, what's wrong 
>> with following the existing practice of referring to TLS 
>> specs elsewhere?

> The intent is that the x86-64 ABI remains a stand-alone document as much as possible.  It's not quite there yet, but adding yet another external reference sets it back even further.

> BTW, the TLS reference is slated to be incorporated into the x86-64 ABI.

>> The point of this posting was more to reserve the relocation 
>> numbers for these purposes (the purpose of the relocations is 
>> quite solid already, even though the numbers have changed as 
>> recently as yesterday), but I'm yet to do some more 
>> performance tests with some minor variations of the code 
>> sequences to choose the best one.  I don't want to have to 
>> maintain all this information in sync between multiple specs 
>> documents and the several different packages that implement 
>> them; having a single specs document is much better for now.

> That's fine.  When it reaches a mature state, patches against the ABI will be more than welcome.

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}

More information about the Binutils mailing list