This is the mail archive of the 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] [MIPS] Compact EH Infrastructure R_MIPS_PC32

"Moore, Catherine" <> 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)))
    return 0;

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
seems wrong.

Maybe something like:

  /* In general, converting to a section-relative relocation can
     increase the addend.  Make sure that we won't lose bits.  */
      reloc_howto_type *howto;
      bfd_vma addr_mask;

      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)
        return 0;

would be better (completely untested).

Looks good otherwise.


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