This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] microMIPS/GAS: Avoid relocation overflow with forced 16-bit branches
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: <binutils at sourceware dot org>
- Date: Thu, 25 Oct 2012 11:19:31 +0100
- Subject: Re: [PATCH] microMIPS/GAS: Avoid relocation overflow with forced 16-bit branches
- References: <alpine.DEB.1.10.1210242342300.9406@tp.orcam.me.uk>
"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> Hi,
>
> The change below fixes a relocation overflow triggered by forced 16-bit
> branches:
>
> $ cat b16.s
> .text
> test1:
> .space 65536
> test2:
> b16 1f
> 1:
> $ mips-linux-gnu-as -mmicromips -o b16.o b16.s
> b16.s: Assembler messages:
> b16.s:5: Error: value of fffffffffffefffe too large for field of 2 bytes at 0000000000010000
> $
>
> Overall it looks to me the whole idea of using fixp->fx_size to check for
> relocatable field overflows is missing the point, at least for the MIPS
> target and relocations in text, where the size of the fixup reflects the
> width of the instruction a relocation is applied to and has little to do
> with the range supported.
>
> Anyway, to fix this immediate problem I have gladly accepted Chao-ying's
> proposal.
>
> No regressions in testing across the usual MIPS targets. OK to apply?
>
> 2012-10-24 Chao-ying Fu <fu@mips.com>
>
> gas/
> * config/tc-mips.c (append_insn): Set fx_no_overflow for 16-bit
> microMIPS branch relocations.
>
> gas/testsuite/
> * gas/mips/micromips-b16.d: New test.
> * gas/mips/micromips-b16.s: New test source.
> * gas/mips/mips.exp: Run the new test.
I take your point about the write.c check (been hit by that before too),
but I suppose the obvious question is: do we still report branches that
genuinely overflow? Although you've used the same wording, this isn't
quite the same as the preceding:
/* These relocations can have an addend that won't fit in
4 octets for 64bit assembly. */
if (HAVE_64BIT_GPRS
&& ! howto->partial_inplace
because in that case the RELA entry contains the full, untruncated addend.
In contrast, 16-bit branches _can_ overflow, just not in the way that
write.c expects.
Would be nice to have a test for that too, if we don't already.
I realise this fix is the same as that used in md_convert_frag for
relaxing microMIPS branches, but the same question applies there
in the "forced to fit" case.
Richard