This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: [patch] MIPS: Follow the ABI rules for ordering HI16_S/LO16 relocs
- From: "Dave Korn" <dk at artimi dot com>
- To: "'Richard Sandiford'" <rsandifo at redhat dot com>,"'Maciej W. Rozycki'" <macro at linux-mips dot org>
- Cc: <binutils at sources dot redhat dot com>
- Date: Tue, 29 Jun 2004 10:17:22 +0100
- Subject: RE: [patch] MIPS: Follow the ABI rules for ordering HI16_S/LO16 relocs
> -----Original Message-----
> From: binutils-owner On Behalf Of Richard Sandiford
> Sent: 29 June 2004 08:07
> To: Maciej W. Rozycki
> "Maciej W. Rozycki" writes:
> > This is one of the fortunate areas the MIPS ABI supplement is clear
> > about. On page 4-18 of the spec, there is the following
> statement:
> > "R_MIPS_LO16 entries without an R_MIPS_HI16 entry
> immediately preceding
> > are orphaned and the previously defined R_MIPS_HI16 is used
> for computing
> > the addend." The implication is for a correct calculation
> of the addend
> > for a LO16 relocation, the corresponding HI16 relocation
> has to precede it
> > with no other HI16 relocations inbetween.
>
> But since the introduction of %lo(), we've always supported the case
> in which one R_MIPS_HI16 has several R_MIPS_LO16s. As a GNU
> extension.
> We shouldn't change that now.
I gotta admit, I don't get this one either.
I can see the difficulty in calculating a high part if there's a
sign-extended carry from the low part that you don't know about, but I don't
see why lo16 calculations can't stand entirely by themselves if they need.
Incidentally, what happens in the case of using the same HI16_S with
several different LO16s that sign-extend differently?
cheers,
DaveK
--
Can't think of a witty .sigline today....