[patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs

[Maciej W. Rozycki]

On Tue, 29 Jun 2004, Richard Sandiford wrote:

> >  Which of course depends on the actual set of objects used, so a single 
> > object may link correctly or not anyway.
> 
> I don't see your point.  Mine is that 16-bit offsets from mergeable
> section symbols are far more common than non-16-bit offsets.

 Yours is of course valid and, well, Linux is pathological here as it does
several incremental relocatable links, so even though initial individual
objects likely only have offsets that fit in 16 bits, ones used for final
linking do not anymore.

 Still I don't think a marginal breakage is better than a common one.  It
may actually be the reverse -- if everything breaks, you immediately
notice something's wrong.  If things break ocassionally, they may stay
unnoticed until they hit badly and you don't really know why.  And you
won't find out unless you are skilled enough to find the offending place,
disassemble it and compare with sources.

> >  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'm not sure where you get the idea that this is specific to 3.4.
[...]
> with a 3.3 mips64-elf compiler using "-O2 -G0".  I get the attached code.

 I wasn't aware explicit relocs were introduced before 3.4.  This fact of 
course invalidates my claim.

> Besides, if we do change the linker, the new behaviour won't appear in
> an official release until 2.16.  (I'm assuming the change would be too
> invasive for 2.15.1, if such a release is made.)  And by the time 2.16
> is out, 3.4 will be fairly old.

 This would be a problem, indeed, but given 3.3 uses explicit relocs, too, 
it's of course irrelevant.

> This might work, but ugh!  It doesn't appeal to me at all.  Maybe the
> maintainers will feel differently though...

 Hmm, have you expected anything nice?  I'm afraid there are not many
options and given two ugly solutions I'd select one that gives the correct
output plus an opportunity to clean up the mess sometime in the future
(hint, hint).

> >  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.
> 
> Depends on context really.  What's .LC33?  If it's only byte-aligned,
> then yes, it's probably a bug.

 Well, even if it's halfword-aligned, then it's still ugly and balancing 
at the edge of the ABI.  Why not:

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

?

  Maciej