Richard Sandiford wrote: > 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). The specification is a co-production of MTI and CS. I believe the reason why it wasn't discussed in a wider audience is that it occured to nobody there could be a parallel effort going on after all those years! > 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). FWIW, I believe a person who is _not_ in the midst of the commercial pressures adds valuable perspective as a maintainer. Thiemo
