RE: [patch] MIPS: Follow the ABI rules for ordering HI16_S/LO16 relocs

["Dave Korn" <dk at artimi dot com>]

> -----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....