Re: [PATCH] MIPS16 TLS support for GCC

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Fri, 3 Feb 2012, Chung-Lin Tang wrote:

> On the issue of hiding stuff in mips16.S, it may be suitable to raise
> this issue here: there is a problem when MIPS16 hard-float calls go
> through PLTs, because the hard-float stub functions in mips16.S use
> v0/v1 as scratch registers, the same as MIPS16 PLT sequences generated
> by BFD. (I think I described the scenario mostly correct, CCing Maciej
> here who worked on this issue)  I think the solution was to mark a large
> portion of the mips16.S functions as all hidden.

 Not quite a large portion, just the function return stubs (which I reckon 
there are exactly four) that process values in $v0/$v1 as if they were 
arguments.  This is of course a non-standard calling convention that 
breaks the ABI and shouldn't be exposed to the dynamic linker and the PLT.  
Not even mentioning that three of these four stubs are not bigger than a 
PLT entry they would need, and the fourth is two or so instructions 
larger, so making them dynamic hardly makes point (the cost of the 
indirect call from PLT also matters).

 Given that this code (to support MIPS16 shared libraries) was obviously 
never fully functional before this effort, I think it is about the right 
time to remove some hacks I saw in glibc's dynamic linker that are meant 
to avoid clobbering $v0/$v1 before someone tries to rely on them for real.  

 And there's no reasonable way to support MIPS16 PLT entries without 
clobbering $v0/$v1 (to preempt your question -- MIPS16 code can of course 
work just fine with standard MIPS PLT entries (no pure-MIPS16 processors 
are possible), but on some processors the cost of flipping the ISA bit is 
prohibitive as it requires draining the pipeline to reconfigure the 
instruction decoder and as such should best be avoided in pure-MIPS16 
dynamic binaries).

  Maciej