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

[Michael Uhler]

> If this is OK with you, I'd appreciate it if you could get 
> back to us about the choice of register number.  I've got at 
> least a couple more days worth of work before the port will 
> be ready.  It won't cripple me to sit on it for a couple 
> weeks after that, but I'd love to have it submitted - I've 
> already started to get requests for the code.

I wouldn't exactly say that it's OK with us.  The impression that I get is
that it's too late to change, and even if it weren't we'd have to prove that
the trap-and-emulate approach had performance problems.  We have to trade
that off with our own desire to get NPTL supported, even if we have a
feeling that the implementation may cause problems in the future.

So, I have allocated RDHWR register 29 (decimal) for use as the pseudo-TLS
pointer.  What this means is that we have changed the architecture documents
to indicate that this register is used for an ABI-related activity such that
it will never be re-allocated for another purpose.  At this point, we do not
intend to implement this as a hardware register, nor will other MIPS
implementations be doing so.  We'll revisit this (as an architecture change)
once we measure the performance impact of the proposal and compare that with
other potential changes to the ABI.

Based on the email thread, I'm not sure if Mark's suggestion of a compromise
by marking the RDHWR with a relocation has benefit or not.  If it does, it
would be nice to have some hedge in the future.

/gmu

---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler at mips.com
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085