This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] [MIPS] Compact EH Infrastructure R_MIPS_PC32
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Moore\, Catherine" <Catherine_Moore at mentor dot com>
- Cc: "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 22 Apr 2013 19:48:52 +0100
- Subject: Re: [PATCH] [MIPS] Compact EH Infrastructure R_MIPS_PC32
- References: <FD3DCEAC5B03E9408544A1E416F11242F8F96D19 at NA-MBX-04 dot mgc dot mentorg dot com>
"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> @@ -17782,6 +17787,10 @@
> if (fixp->fx_addsy == NULL)
> return 1;
> + /* Alow relocs used for EH tables. */
> + if (fixp->fx_r_type == BFD_RELOC_32_PCREL)
> + return 1;
> /* If symbol SYM is in a mergeable section, relocations of the form
> SYM + 0 can usually be made section-relative. The mergeable data
> is then identified by the section offset rather than by the symbol.
I think this is really trying to circumvent the later:
/* There is no place to store an in-place offset for JALR relocations.
Likewise an in-range offset of PC-relative relocations may overflow
the in-place relocatable field if recalculated against the start
address of the symbol's containing section. */
&& (fixp->fx_pcrel || jalr_reloc_p (fixp->fx_r_type)))
I'm not sure it's correct for ELF64 though, where the range of the
relocation is still smaller than the address range. I realise the
cases where it matters are very much corner cases, but it still
Maybe something like:
/* In general, converting to a section-relative relocation can
increase the addend. Make sure that we won't lose bits. */
howto = bfd_reloc_type_lookup (stdoutput, fixp->fx_r_type);
addr_mask = ((bfd_vma) 1 << (HAVE_64BIT_OBJECTS ? 63 : 31) << 1) - 1;
if ((howto->src_mask & addr_mask) != addr_mask)
would be better (completely untested).
Looks good otherwise.