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

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

On Mon, 1 Nov 2010, Richard Sandiford wrote:

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

 It looks I've had that binutils-*-mips-reloc-got-offset.patch change 
outstanding for a couple of years too. ;)

  Maciej