linux-mips
[Top] [All Lists]

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

To: binutils@sourceware.org, gcc@gcc.gnu.org, linux-mips@linux-mips.org, rdsandiford@googlemail.com
Subject: Re: RFC: Adding non-PIC executable support to MIPS
From: Thiemo Seufer <ths@networkno.de>
Date: Wed, 2 Jul 2008 11:13:56 +0100
In-reply-to: <87zlp149ot.fsf@firetop.home>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <87y74pxwyl.fsf@firetop.home> <20080701202236.GA1534@caradoc.them.org> <87zlp149ot.fsf@firetop.home>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
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

<Prev in Thread] Current Thread [Next in Thread>