Daniel Jacobowitz <dan@xxxxxxxxxx> writes: > We've shipped our version. Richard's version has presumably also > shipped. Right. > We did negotiate the ABI changes with MTI; this is not quite > as good as doing it in full view, but it was the best we could manage > and MTI is as close to a central authority for the MIPS psABI as > exists today. > > Richard, what are your thoughts on reconciling the differences? You > can surely guess that I want to avoid changing our ABI now, even for > relatively significant technical reasons - I'm all ears if there's a > major reason, but in the comparisons I do not see one. I suppose I still support the trade-off between the 5-insn MIPS I stubs (with extra-long variation for large PLT indices) and the absolute .got.plt address I used. And I still think it's shame we're treating STO_MIPS_PLT and STO_MIPS16 as separate; we then only have 1 bit of st_other unclaimed. However, IMO, your argument about MTI being the central authority is a killer one. The purpose of the GNU tools should be to follow appropriate standards where applicable (and extend them where it seems wise). So from that point of view, I agree that the GNU tools should follow the ABI that Nigel and MTI set down. Consider my patch withdrawn. TBH, the close relationship between CodeSourcery and MTI make it difficult for a non-Sourcerer and non-MTI employee to continue to be a MIPS maintainer. I won't be in-the-know about this sort of thing. I've been thinking about that a lot recently, since I heard about your implementation. I kind-of guessed it had been agreed with MTI beforehand (although I hadn't realised MTI themselves had written the specification). Having thought it over, I think it would be best if I stand down as a MIPS maintainer and if someone with the appropriate commercial connections is appointed instead. I'd recommend any combination of yourself, Adam Nemet and David Daney (subject to said people being willing, of course). Richard
