Richard Sandiford wrote:
> Daniel Jacobowitz <firstname.lastname@example.org> writes:
> > We've shipped our version. Richard's version has presumably also
> > shipped.
> > 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
> 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.