This is the mail archive of the
mailing list for the binutils project.
Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: "Maciej W. Rozycki" <macro at linux-mips dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 03 Jul 2004 11:46:41 +0100
- Subject: Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
- References: <Pine.LNX.firstname.lastname@example.org><email@example.com> <firstname.lastname@example.org><email@example.com><Pine.LNX.firstname.lastname@example.org><email@example.com><Pine.LNX.firstname.lastname@example.org><email@example.com><Pine.LNX.firstname.lastname@example.org><email@example.com><Pine.LNX.firstname.lastname@example.org>
"Maciej W. Rozycki" <email@example.com> writes:
> 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?
Gah! I hate to say this, but I'm still not convinced. I just don't think
that the cost/benefit balance makes it worth reordering the relocations.
(1) Any software that relied on the order of LO16 relocations would
have the same problem that we had with the linker; namely, there'd
be no way of telling whether an object follows the rule or not.
(2) This problem only occurs when using explicit relocation operators
on REL targets. I think that's a GNU-specific feature. And it's
a feature that already relies on a GNU extension, since we allow
several high-part relocations to chain onto the same low-part
The placement of LO16 relocations has been a defacto extension
along the same lines. We can effectively say: if your software
needs to cope with explicit-reloc REL objects, you need to treat
LO16 relocations as having stand-alone offsets, and have to cope
with several high-part relocations being associated with the same
(3) I'm strongly opposed to an unconditional warning on:
I'm about to post a patch with more rationale, so if you disagree,
please reply to that message rather than this one ;)
(4) The reordering doesn't fall out it in the wash. It needs a separate,
quadratic, pass over the relocations. That seems like quite a big
overhead for something that has no specific use.
(5) The gas/bfd reloc code has been the source of many, many bugs over
the last few years. I've lost count of how many there've been.
Again, I don't like the idea of munging the relocs without there
being a specific use for it.