Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs

[Richard Sandiford <rsandifo at redhat dot com>]

"Maciej W. Rozycki" <macro@linux-mips.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.
Several reasons:

  (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
      relocation.

      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
      low-part relocation.

  (3) I'm strongly opposed to an unconditional warning on:

            lui $4,%hi(foo)
            addiu $4,$4,%lo(foo+2)

      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.

Richard