"Maciej W. Rozycki" <ma...@codesourcery.com> writes: > 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).
But that isn't the only reason to use shared libraries. > 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. FSF BFD doesn't generate MIPS16 PLTs though. Is this a CS-local change? If so, the criticism seems a little unfair. The FSF code is self- consistent: PLTs can be used for these stubs because the resolver function preserves the necessary registers. Traditional lazy binding stubs are avoided by not using %call16. I don't think changing the resolver function so that it preserves fewer registers would be a good idea. As well as the MIPS16 thing, $3 is needed for _mcount. You're right of course that PLTs can't be used for __mips16_rdhwr. I'd forgotten about that, sorry. Will fix this weekend. 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? Richard
