[PATCH] MIPS16 TLS support for GCC

[Richard Sandiford]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>> >  We have only about now got MIPS16 shared libraries to work -- are you 
>> > sure removing code to save/restore $2/$3 in the dynamic linker is going to 
>> > hit anyone?
>> 
>> Pretty sure.  There are two separate points here.  Support for MIPS16
>> shared libraries went into the FSF tools in 2008, and I was able to
>> build working(!) shared libraries at that time.  (To be clear, these were
>> external libraries rather than things like libgcc.)  So it's not really
>> that new.
>> 
>> That doesn't mean that there weren't bugs in the implementation, of course.
>> But I think we're just going to have to agree to disagree on the
>> "working" thing.  It's probably moot anyway given the other point...
>
>  OK, perhaps soft-float (or if you happened to avoid FP altogether) could 
> have worked.  With hard float we hit problems at least with symbol 
> references emitted incorrectly by GCC in the context of some MIPS16 thunks 
> as well as binutils failing to emit LA25 thunks for some MIPS16 thunks.  
> So it wasn't just MIPS16 shared libraries that failed, but also dynamic 
> MIPS16 executables.  So it looks to me like a part of the MIPS16 ABI 
> wasn't covered at all (I'd expect all the "interesting" cases to have been 
> deliberately tested before claiming victory).

It was hard-float too FWIW.  As with all these things, some applications
just have a knack of avoiding certain bugs :-)

>> >> If there's still some concern that __mips16_rdhwr might not have
>> >> the right ABI, then maybe we should simply emit a link-once function
>> >> in each object that needs it.  We could then switch to another function
>> >> (and another API) without having to keep the old one in libgcc.a for
>> >> compatibility.  It would also avoid the -shared-libgcc thing.
>> >> 
>> >> Admittedly that's just an off-the-top-of-my-head idea. :-)
>> >> What do you think?
>> >
>> >  Actually I had that idea of a link-once function too, but it turned out 
>> > quite complicated to do without rewriting some generic parts of GCC as it 
>> > is currently not prepared to emit link-once functions outside C++ 
>> > compilations.  It's been a while and I did lots of other stuff meanwhile, 
>> > so please excuse me if I got anything wrong here.
>> 
>> Hmm, OK, I wouldn't have expected that.  But if you've tried making
>> __mips16_rdhwr link-once and had a bad experience with it, then yeah,
>> let's go with the hidden libgcc function.  It's just a shame that we're
>> having to force static linking of libgcc for this one case.
>
>  Well, it's just this single function that's pulled from libgcc.a -- all 
> the rest will come from libgcc_s.so (unless hidden as well, that is).  
> The benefit is you can always change the ABI of __mips16_rdhwr without 
> worrying about existing executables -- they'll continue to work using 
> their private piece of code unchanged.

We can't change the ABI of __mips16_rdhwr.  As I was saying before,
we need to keep this function around from now on so that static
libraries that contain objects built with gcc 4.7 can be linked
by later compilers (which will link against their own libgcc.a).
If we come up with another interface, the function will need to
have a new name, and we'll need to continue to provide the current
__mips16_rdhwr in libgcc.a for compatibility reasons.

Richard