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

[Thiemo Seufer <ths@networkno.de>]

Richard Sandiford wrote:
> 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).

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