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

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Sat, 3 Jul 2004, Richard Sandiford wrote:

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

 Sure, but that doesn't stop it being a bug.  Future software could rely
on the order.

>   (2) This problem only occurs when using explicit relocation operators
>       on REL targets.  I think that's a GNU-specific feature.  And it's

 Unfortunately I may have troubles checking if this is true or false.

>       a feature that already relies on a GNU extension, since we allow
>       several high-part relocations to chain onto the same low-part
>       relocation.

 Which IMHO makes little sense unless all these high-part relocations 
refer to the same symbol+addend.  Even then it's of dubious use.

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

 OK, how about we change the ABI first (which is even quite reasonable in 
this area) and only then implement the changes?

>   (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 ;)

 I've already agreed with you on this, haven't I?

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

 That's a valid point of concern, but this is a problem with the
implementation, not the concept.  And this is already solved for %hi
relocations -- they are recorded during assembly as they are discovered.  
A similar setup could be done for %lo ones.

 And perhaps a different data structure should be used for keeping
relocations while processing.

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

 I feel some of the bugs could have been and still can be avoided by doing 
actual fixes instead of trying to do workarounds for special cases.  But 
that's just my opinion -- feel free to disagree.

  Maciej