This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] microMIPS/GAS: Avoid relocation overflow with forced 16-bit branches


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]