Re: RFC: Adding non-PIC executable support to MIPS

[Richard Sandiford <rdsandiford@googlemail.com>]

Daniel Jacobowitz <dan@debian.org> 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