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