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
