Re: [PATCH] MIPS/GAS: Fix NewABI reloc handling with the LD/SD macro

[Richard Sandiford <rdsandiford@googlemail.com>]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>> >> This may be a known bug, and is certainly nothing to do with your patches,
>> >> but I notice:
>> >> 
>> >> 	ld	$4,0x7ffc($5)
>> >> 
>> >> fails to work correctly (or trigger a diagnostic) in o32 mode.
>> >> 0x8000 works fine of course.
>> >
>> >  You didn't like my patch addressing this issue back here:
>> >
>> > http://sourceware.org/ml/binutils/2005-02/msg00610.html
>> >
>> > (originally here: http://sourceware.org/ml/binutils/2004-06/msg00530.html)
>> >
>> > but I've kept maintaining it locally over the years (and got it up to 
>> > 2.20; obviously with the recent changes it'll require an update, but I 
>> > planned to do that anyway while upgrading the RPM packages I maintain).  
>> > If you'd like me to get it refreshed and resubmitted, then I am all for 
>> > it.
>> 
>> No, I stand by what I said there.  IMO the reloc case isn't interesting
>> for the reasons discussed in that thread.  The o(b) case _is_
>> interesting because it is inconsistent with the corresponding
>> o(b) behaviour for unaligned loads and stores.
>
>  I am confused.  The very purpose of that patch 
> (binutils-*-mips-dword-reloc.patch, for the avoidance of doubt) is to 
> avoid an overflow from 0x7ffc wrapping to -0x8000.
>
>  If you're concerned about my proposal pessimising code for a corner case 
> where one of two LO16 relocs sharing a common HI16 reloc has a carry at 
> the link stage into the HI16 reloc while the other one does not, then 
> perhaps it would be enough if LD just failed the link complaining about 
> this problem instead?  Then we would only have to take care of the 
> immediate addend of 0x7ffc.  The drawback is if the LD error is hit, the 
> user would have to sort out the problem himself and frankly "rearranging 
> code so that the symbol <foo> has its final address different to <addr>" 
> sounds rather like a dodgy solution to me.

I'm talking specifically about the case where no relocations are involved,
i.e. where the offset is a constant integer.  And yeah, the inconsistency
I mentioned is precisely that uld & co.  will issue a diagnostic in this
case.  I think that's what we should do for ld & sd as well.

Richard