[patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs

Maciej W. Rozycki macro@linux-mips.org
Fri Jul 2 16:05:00 GMT 2004

On Wed, 30 Jun 2004, Richard Sandiford wrote:

> Just for the record: full explicit reloc support (as controlled by
> -mexplicit-relocs) _is_ new to 3.4.  But gcc has been able to use
> %hi() and %lo() for many years.  Certainly as far back as 2.95.
> This limited form of explicit reloc support was controlled by
> -msplit-addresses and was enabled by default when optimising
> and using gas.  According to the changelogs, it was added to
> public gcc sources in April 1997.

 I stand corrected.  Thanks for clarification.

> Agreed that we have a choice between two ugly solutions.  I still
> think there are arguments in favour of the ugly gas patch though.
> The main one is that it leaves the door open to accurate warnings.
> In other words: as a separate patch, we could get the linker to warn
> about _all_ high-part relocations against mergeable section symbols
> in which the high-part offset is nonzero.  This will catch existing
> objects that are susceptible to the bug while giving very few false
> positives.
> In contrast, with your patch, we would have a legitimate use for
> such relocations, so we couldn't easily tell whether the object
> is faulty or not.  (This is the point you made in (3) in your
> earlier mail.)  And the number of false positives would be high,
> since we would warn about 16-bit offsets that the old linker
> would have handled correctly.

 Well, I've just realized that the proposals are mostly orthogonal.  The
only bit that we disagree about is the use of the high part in
_bfd_mips_elf_relocate_section(), which can be avoided with your gas hack.  
That's probably a violation of the ABI, but perhaps no one notices. ;-)  
But we can still conform to the ABI and reorder relocations properly, so
that objects are correct and will be handled properly by any software.

 So I propose to replace my "mips-merge-lo16" patch with your gas hack,
add the warning you suggest above and apply the rest of my patches anyway.  
Does it sound reasonably?

> BTW, if we go for the new interpretation of LO16 relocs, are you
> that sure only _bfd_mips_elf_relocate_section needs changing?

 I'm not.

> What about the howto functions?

 Hmm, bfd_perform_relocation() may indeed need investigation; 
bfd_install_relocation() should be safe, though, as it seems to be used 
for initial creation only.


More information about the Binutils mailing list