[mips-tls] A couple of potential changes to the MIPS TLS ABI

[Dominic Sweetman]

Daniel,

> We have the 32-bit port of NPTL basically working now, and I have been
> preparing the first patches for submission - which means binutils.  So
> I have been going over the ABI in some detail looking for things that
> we want to finalize before the patches are integrated.  I found three
> points...

Thanks, ace work.  I hope we'll be in a position to pick this stuff up
fairly soon and beat on it.

> Second, the %tpoff operator is currently ambiguous.  When we say
> %dtpoff, we are always talking about the offset from the base of this
> module's DTV entry to the location of the variable; currently this is
> always used with %hi and %lo.  However, %tpoff can be used with %hi and
> %lo (Local Exec model, refers to variable offset from thread pointer)
> %or without (Initial Exec model, refers to GOT slot holding the
> variable offset).
> 
> How about this instead?
>   R_MIPS_TLS_TPOFF -> R_MIPS_TLS_GOTTPOFF
>   %tpoff(x)($28) -> %gottpoff(x)($28)

Sounds better.

> Third, the Design Choices section of the specification has this to say:
> 
>      *  The compiler is not allowed to schedule the sequences below. 
> 
>   The sequences below must appear exactly as written in the code
>   generated by the compiler. This restriction is present because we have
>   not yet determined what linker optimizations may be possible. In order
>   to facilitate adding linker optimizations in the future, without
>   recompiling current code, the compiler is restricted from scheduling
>   these sequences. 
> 
> I'd like to settle this one way or the other before finalizing the
> spec.

Why not sit on the fence?  See below.

> The major advantage here is replacing a call to __tls_get_addr with a
> rdhwr instruction.  These are, in theory, doable for MIPS.

Mike Uhler responded separately about MIPS Technologies' position on
using rdhwr for this purpose.

For NUBI we plan to reserve a general purpose register for a thread
pointer, making the optimization a bigger win.

> There are a couple of other quirks for this; the only one I can think
> of offhand is MIPS-I load delay slots, which would mean neither
> sequence could be used as-is.

There are relatively few MIPS-I machines out there.  Would it be
unacceptable if the standard NPTL system failed to work on them?

> The immediate disadvantage is that the compiler can not schedule the
> sequences.  I don't know what all the tradeoffs are here, I just
> know that the compiler implementation would be simpler if we did not
> make the sequences fixed and unschedulable.
> 
> So I'd like to ditch that unless folks think that
>   (A) the linker optimizations are useful
>   (B) the linker optimizations are feasible
>   (C) someone is likely to implement the linker optimizations
> 
> Any opinions?  I see that Alpha does implement the TLS linker
> relaxations; on the other hand, Alpha already had a linker relaxation
> mechanism in place, and the GNU tools for MIPS don't.

Why not re-write the spec to say "unless you generate this sequence
exactly like this, you'll probably prevent any future linker
optimization from working" - and then leave it to the compiler
toolchain. 

My opinion is that linker optimizations could be very valuable, given
a cheap way of accessing a thread pointer.  But MIPS Technologies are
very unlikely to do heroic work on the linker for the o32 ABI - but we
do intend to at least try that out for our NUBI ABI.

-- 
Dominic Sweetman, 
MIPS Technologies (UK)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200
http://www.mips.com