[patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs
Sat Jul 3 10:46:00 GMT 2004
"Maciej W. Rozycki" <firstname.lastname@example.org> 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.
More information about the Binutils