Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Tue, 29 Jun 2004, Richard Sandiford wrote:

> > 2. Warning messages for many cases (unfortunately not all, but information
> > is lost already) when a previously built object is malformed and may
> > produce a broken binary.  I think this is the case you refer to above,
> > writing: "[...] it would silently mishandle existing references to
> > mergeable section symbols + offsets."  It's neither a worse mishandling
> > than the current one -- the offset will be left intact as for an ordinary
> > section -- nor actually a silent one.
> 
> Well, the current linker correctly handles any LO16 relocations in which
> the high part of a mergeable section offset is zero.  Even if the LO16
> relocation isn't paired to a HI16 or GOT16.

 Which of course depends on the actual set of objects used, so a single 
object may link correctly or not anyway.

> With your patch, orphaned LO16 relocations will take the high bits of
> the offset from the previous HI16 relocation, whatever that happens to be.
> That runs a high risk of introducing silent breakage when used with
> old binaries.

 And gcc 3.4 is out for how long?  Two months.  Do you think all the 
people rushed out to rebuild all their binaries with a new release?  I 
don't.

 I think there is a way to deal with it gracefully and still do the right 
fix.  You worry about the case where there is an orphaned LO16 relocation 
that happens to work currently, beacuse:

1. The offset of its corresponding HI16 relocation is zero.

2. There's another HI16 relocation preceding the relocation and its offset 
is non-zero.

Is that right?  How about detecting this case and warning the user upon
linking?  I think it can be detected thus:

Given a LO16 relocation:

1. If the offset of the preceding HI16 relocation is zero, then proceed 
normally.

2. If the offset of the preceding HI16 relocation is non zero and the
symbol referred to is not the one referred to by this relocation, then the
object was created by broken gas.  Issue a warning.  Optionally assume the
high part of the offset is zero.

3. If the offset of the preceding HI16 relocation is non zero and the
symbol referred to is the same, then proceed normally.  The resulting
binary would be broken when built with current ld anyway as the
non-orphaned LO16 relocation corresponding to the preceding HI16 (which
may or may not be one currently being processed) would not use the high
part of the offset.  We don't know if the object is good or bad, so no
warning.  Alternatively, perhaps we may mark good objects somehow and
issue a warning here for non-marked ones.

> > 3. Warning messages for sources that use %hi and %lo operators in a
> > dangerous way.  I was quite surprised having discovered GCC is an offender
> > here.
> 
> Can't respond to this unless you give examples.  Note that gcc does
> deliberately create orphaned LO16 relocations in cases like:
> 
>         lui     $2,%hi(.LC1)
>         lwc1    $f0,%lo(.LC1)
>         lwc1    $f1,%lo(.LC1 + 4)
> 
> where LC1 is known to be double-word aligned.  Is this the kind
> of case you're talking about?

 I've seen something like this:

	lui	$6,%hi($LC33)
	lbu	$6,%lo($LC33+1)($6)

which I can't really see a reasonable explanation for -- for me it's a
plain bug.  Your example seems to be something like this:

        lui     $2,%hi($LC7)
        lbu     $fp,%lo($LC7+1)($2)
        lbu     $23,%lo($LC7)($2)

which would indeed be safe with appropriate alignment constraints.  I'll 
have a look at how to make the relocs match in this case.  This would 
probably cover the previous case, too, as long as alignment permits.

  Maciej