RE: RFC: TLS improvements for IA32 and AMD64/EM64T

["Menezes, Evandro" <evandro.menezes@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

Hi, Alexandre. 

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

It looks good and the patch is pretty informative.  However, there are some statements that may not be as clear as they could be, so I was thinking if the changes to your patch in attach seem reasonable.

Would you consider adding the calculations for the new relocations in order to improve their clarity?  The original paper on TLS goes on about them a bit, but it wouldn't be a bad idea to have the psABI document more stand-alone.

I remember some examples in your paper at the GCC Summit and adding them to section 3.5 would be swell too.

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

From your paper at the GCC Summit it's quite clear that such additions to the psABI would be a fine idea.  Perhaps HJ would like to consider the corresponding additions for the i386 psABI extension.

So, there's no question about the technical part of your proposal.  But, as you can infer from my comments above, I'd like to improve the clarity of the psABI so that one wouldn't have to go to specific implementations to figure out the details.  What do you think?

Thank you,

-- 
_______________________________________________________
Evandro Menezes               AMD            Austin, TX


[-- Attachment #2: tlsdesc.patch.patch --]
[-- Type: application/octet-stream, Size: 2048 bytes --]

--- tlsdesc.patch	2006-10-09 14:32:25.739161000 -0500
+++ tlsdesc.patch.new	2006-10-09 14:38:53.597399000 -0500
@@ -115,10 +115,10 @@ Index: object-files.tex
 +linker generates such relocations in adjacent entries in the GOT, in
 +response to \texttt{R_X86_64_TLSGD} and \texttt{R_X86_64_TLSLD}
 +relocations.  If the linker can compute the offset itself, because the
-+referenced symbol binds locally, the \texttt{DTPOFF} may be omitted.
++referenced symbol binds locally, the relocations \texttt{R_X86_64_64} and \texttt{R_X86_64_32} may be used instead.
 +Otherwise, such relocations are always in pairs, such that the
-+\texttt{DTPOFF64} relocation applies to the word64 right past the
-+corresponding \texttt{DTPMOD} relocation.
++\texttt{R_X86_64_DTPOFF64} relocation applies to the word64 right past the
++corresponding \texttt{R_X86_64_DTPMOD64} relocation.
  \end{sloppypar}
  
 +\texttt{R_X86_64_TPOFF64} and \texttt{R_X86_64_TPOFF32} resolve to the
@@ -129,12 +129,12 @@ Index: object-files.tex
 +
 +\texttt{R_X86_64_TLSGD} and \texttt{R_X86_64_TLSLD} both resolve to
 +PC-relative offsets to a \texttt{DTPMOD} GOT entry.  The difference
-+between them is that, for \texttt{TLSGD}, the following GOT entry will
++between them is that, for \texttt{R_X86_64_TLSGD}, the following GOT entry will
 +contain the offset of the referenced symbol into its TLS block,
-+whereas, for \texttt{TLSLD}, the following GOT entry will contain the
++whereas, for \texttt{R_X86_64_TLSLD}, the following GOT entry will contain the
 +offset for the base address of the TLS block.  The idea is that adding
-+this offset to the result of \texttt{DTPMOD32} for a symbol ought to
-+yield the same as the result of \texttt{DTPMOD64} for the same symbol.
++this offset to the result of \texttt{R_X86_64_DTPMOD32} for a symbol ought to
++yield the same as the result of \texttt{R_X86_64_DTPMOD64} for the same symbol.
 +
 +\texttt{R_X86_64_TLSDESC} resolves to a pair of word64s, called TLS
 +Descriptor, the first of which is a pointer to a function, followed by