This is the mail archive of the
mailing list for the binutils project.
Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 2 Jul 2004 18:05:33 +0200 (CEST)
- Subject: Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- References: <Pine.LNX.email@example.com><firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org><Pine.LNX.email@example.com> <firstname.lastname@example.org>
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
> 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?
> 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.