This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: On resolving the MIPS gas branch reloc issue


On 26 Feb 2003, Eric Christopher wrote:

> > The alternative would be to simply allow the GNU extension reloc for the
> > other ABIs, but then GNU binutils won't be compatible to other toolchains.
> > I forgot to mention that the SDE MIPS Tools (formerly Algorithmics, now
> > AFAIK the official MIPS toolchain) have used R_MIPS_PC16 for years in the
> > way my patch does now for binutils.
> 
> I care less about compatibility with other tools than doing the right
> thing here. Why don't we have a friendly local MIPS licensee talk to
> them?

 I hope the following statement from Dominic Sweetman clears any doubt.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro at ds2 dot pg dot gda dot pl, PGP key available        +

---------- Forwarded message ----------
Message-ID: <15967 dot 10141 dot 166760 dot 373070 at arsenal dot mips dot com>
Date: Fri, 28 Feb 2003 09:10:53 +0000
From: Dominic Sweetman <dom at mips dot com>
To: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>,
    Linux-MIPS <linux-mips at linux-mips dot org>
Cc: Mike Uhler <uhler at mips dot com>, "Kevin D. Kissell" <kevink at mips dot com>,
    Nigel Stephens <nigel at mips dot com>, Dominic Sweetman <dom at mips dot com>,
    Ralf Baechle <ralf at linux-mips dot org>
Subject: Re: The MIPS' statement on R_MIPS_PC16 relocations


Maciej W. Rozycki (macro at ds2 dot pg dot gda dot pl) writes:

> Thiemo wants to reimplement R_MIPS_PC16 relocations to be useful for
> branches which requires a relocation's addend to be shifted left by two
> before processing and then shifting a calculated value right by two before
> applying to the relocated field (similarly to what is done for R_MIPS_26
> relocations).  The ABI currently defines these relocations to be handled
> without any shifts rendering them useless for branches and probably
> anything else.  I suspect that may actually be a typo or a
> misunderstanding that happened when working on the document. 

The existing definition is nonsense - I won't guess how it happened,
but there's no reason to keep it.  Thiemo has MIPS Technologies'
thanks and blessing in making this change.  Please let our Nigel
Stephens know when it's done (mailto:nigel at mips dot com) and he'll
double-check it.

I'm sure you'll put comments in the code noting that this is different
from the document.

There's a more tricky question, which is how we're going to document
this.  I'm currently trying to create a more user-friendly (and
accurate) ABI document, but had not yet got to the relocation types...

-- 
Dominic Sweetman, 
MIPS Technologies (UK)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200
http://www.mips.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]