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

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Michael Uhler wrote:

> In terms of the ship leaving the dock, is the issue one of specifically
> rdhwr, or could we use another instruction which also traps as an RI (or
> something else that isn't a syscall)? I'll talk more about rdhwr below, but
> it's important for me to understand whether it's the instruction, or the
> mechanism that makes you believe that the technical window has passed.
I think it's the mechanism, but Daniel could answer more definitively. 
I know that there's a kernel patch out there to interpret the rdhwr 
instruction -- but from the toolchain point of view I can't see any 
reason to think that any single instruction couldn't be used just as well.
> The alternatives seem to be to use a GPR (but this requires an ABI change)
> or to park the TLB  pointer someplace in the address space. I wondered to
> Mark at one point whether we could put it at the base of the stack, then
> down-align sp to access it.  We played with this a bit, but couldn't come up
> with anything that was relatively clean.
I don't remember quite what happenned to the idea of putting the value 
at some known location in memory.  I think that Dan shot this down 
relatively effectively, but I can't remember on quite what basis.  One 
downside is that it means that all implementations will always be 
somewhat inefficient; you're going to take a memory access hit, no 
matter what improvements are made to the architecture.
> So my feedback on the use of rdhwr (or any other instruction that traps) is
> that as long as this is a short-term solution and/or we understand the
> performance implications of how often that trap happens, it's OK.  Depending
> on rdhwr to appear in a real implementation any time in the next 2-3 years
> simply isn't going to happen.
I think that matches our expectations.  My understanding is that we'll 
have a new MIPS ABI, probably with a GPR for the thread pointer, by
then.  So, I think we should view this as short-term hack to o32.

--
Mark Mitchell
CodeSourcery, LLC
mark@xxxxxxxxxxxxxxxx
(916) 791-8304