This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS/GAS: Fix NewABI reloc handling with the LD/SD macro
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 1 Nov 2010 10:35:38 +0000 (GMT)
- Subject: Re: [PATCH] MIPS/GAS: Fix NewABI reloc handling with the LD/SD macro
- References: <alpine.LFD.2.00.1010241201020.15889@eddie.linux-mips.org> <87wrp6m03j.fsf@firetop.home> <alpine.LFD.2.00.1010311914200.25426@eddie.linux-mips.org> <g4y69dzb35.fsf@richards-desktop.stglab.manchester.uk.ibm.com>
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