This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: break MIPS16 TLS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]