PATCH: break MIPS16 TLS

Sandra Loosemore sandra@codesourcery.com
Wed Sep 5 16:24:00 GMT 2007


Jakub Jelinek wrote:
> On Tue, Sep 04, 2007 at 08:33:17AM -0400, Sandra Loosemore wrote:
>> Richard and I have previously been discussing this change in the context 
>> of the MIPS16 function attributes patch.  Yesterday we had some internal 
>> discussion and realized we were talking about doing different things; 
>> so, for avoidance of ambiguity, this patch is my current understanding 
>> of the change Richard wants me to make.  It's actually completely 
>> independent of the MIPS16 function attributes patch, so I've split it 
>> off for separate consideration.
>>
>> I'm still trying to figure out what to do with the testsuite, since this 
>> change intentionally breaks all the TLS tests with -mips16.
> 
> I don't see how this can be a good thing.
> If the target can't support taking address of a __thread variable,
> then it should IMNSHO use emutls.
> Emutls was added so that all targets can support __thread and so that
> code can assume it and use it portably.  If MIPS16 has crippled __thread
> support, then that's suddenly not true.

But the alternative is having TLS code that isn't ABI compatible between 
files compiled with -mips16 and those without, which could lead to 
subtly incorrect behavior in user code.  E.g. consider two files, each 
of which contains a tentative declaration of what they think is the same 
top-level TLS variable.  If one file is compiled with -mips16 and gets 
emutls, and the other with -nomips16 so it gets the native MIPS32 TLS 
support, you might not even get a link error, just each file merrily 
using its own copy in its own way.  Far better just to tell the user 
"this doesn't work".

The "right" solution, as Richard already said, is to make the native TLS 
stuff work in MIPS16 mode too.  But there are a lot of other features 
that are not yet supported with MIPS16 as well, and limited amounts of 
people who have the knowledge and time to add them.....

-Sandra



More information about the Gcc-patches mailing list