[mips-tls] Revised versions of MIPS TLS ABI specification

[Daniel Jacobowitz]

On Thu, Oct 28, 2004 at 12:47:52PM -0700, Mark Mitchell wrote:
> I've attached a revised version of the specification.
> 
> As you will see from the revision history at the top, the only changes 
> I've made are the incorrect uses of "$(3)" found by Nigel.
> 
> I've also added an Open Issues section, where I've attempted to record 
> the issues raised thus far.  My priority (well, MontaVista's priority) 
> is to get the basics nailed down so that we can start implementing them 
> ASAP.  That means that I would prefer to get consensus about the basics 
> of the specification, even if there are some bits that we want to add in 
> the future.
> 
> I would like to get the GD/LD bits specified first, so we can start 
> implementing; then we can come back and LE/IE.  Thus, I think the 
> following issues are all things that we can decide later, given that at 
> the moment we're talking only about General Dynamic and Local Dynamic. 
> 
> 1. Add |-mxgot| support.
> 
> We want to do this, for sure, but it does not affect General Dynamic, 
> and it is clear that this can be added to Local Dynamic without 
> impacting the currently specified functionality.

Yes, it does affect GD.  This instruction:

    0x08 addiu $4, $28, %tlsgd(x)               R_MIPS_TLS_GD   x  

assumes that the GD entry in the GOT is within 64k of $28; this
assumption prohibits the use of xgot.  However, like the rest of xgot,
this can wait a little longer.

> 3. Should we use Model I or Model II from Drepper's paper?
> 
> This issue does not arise for Global/Local Dynamic.

Well, not for the binutils and GCC portions of the implementation,
anyway.

> 4. Does __tls_get_addr need a special calling convention?
> 
> This issue does not matter until we start doing linker optimizations.  
> Until that time, the compiler can be conservative, and assume this is an 
> ordinary call.
> 
> The following issue does need resolution:
> 
> 1. Should we extend the 32K Local Dynamic Model to 64K by using a biased 
> offset?
> 
> Daniel and I thought this would be more trouble than it's worth; Thiemo 
> thinks otherwise.  Are there any other opinions?

I have since learned that PowerPC already does this:

| The PowerPC32 TLS ABI is similar to the PowerPC64 model.  The
| thread-local storage data structures follow variant I.  The TCB is 8
| bytes, with the first 4 bytes containing the pointer to the dynamic
| thread vector. tlsoffset calculations and definition of __tls_get_addr
| are identical to PowerPC64.  r2 is the thread pointer, and points
| 0x7000 past the end of the thread control block.  Dynamic thread vector
| pointers point 0x8000 past the start of each TLS block.  (*) This
| allows the first 64K of each block to be addressed from a dtv pointer
| using fewer machine instructions.  The tp offset allows for efficient
| addressing of the TCB and up to 4K-8 of other thread library
| information.
| 
| (*) For implementation reasons the actual value stored in dtv may point
| to the start of a block, however values returned by accessor functions
| will be offset by 0x8000.

So for local dynamic, offsets would be biased by 0x8000 instead of 0;
for initial exec, offsets would be biased by -0x7000 instead of +8. 
This leaves room for the pthread descriptor to be accessed in a single
instruction as long as it is no more than 4k-8 bytes.

Shall we use this model?

-- 
Daniel Jacobowitz