This is the mail archive of the
mailing list for the binutils project.
Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 15 Jul 2004 15:00:41 +0200 (CEST)
- Subject: Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- References: <Pine.LNX.email@example.com><firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org>
On Wed, 14 Jul 2004, Richard Sandiford wrote:
> Where we disagree is that this (the placement of LO16s) is a bug in the
> first place. Like I say, you only get the "out of place" (in your opinion)
> LO16s with REL relocations generated from explicit reloc expressions.
> That's already extension territory.
That's not an extension in the sense of the MIPS ABI at all. The means
of generating relocations from source code are out of the scope of the
MIPS ABI as it is a binary interface spec, not a source one, after all.
You can write your own compiler that generates object code directly from a
source written in some language (it can be any high-level language or even
assembly with a different syntax) and still comply to the ABI.
In fact the MIPS ABI document itself uses abstract operators for
constructing expressions that are expected to emit relocations (like
"foo_got_off") in the few assembly examples it provides. There is no
reason a reasonable language compiler like GNU as couldn't implement them.
> We obviously aren't going to reach agreement on this, so there's
> probably little point me saying any more.
Well, if you say so, then I can't argue. I hope you have serious
arguments to support your claim. You've failed to prove me "my opinion"
disagrees with the MIPS ABI or at least that it's not the only valid
You may certainly say that your intent is to violate the ABI in this
respect for performance reasons you've already signalled or any others and
that may actually be acceptable provided it's stated explicitly and
documented at least in the sources. That wouldn't be the first place we
diverge from a written standard. You haven't done that yet, though.