Re: PR28306, segfault in _bfd_mips_elf_reloc_unshuffle

[Alan Modra <amodra@gmail.com>]

On Thu, Sep 09, 2021 at 11:51:48AM +0200, Maciej W. Rozycki wrote:
> On Wed, 8 Sep 2021, Alan Modra wrote:
> > +  /* ld -r or gas.  */
> >    relocatable = (output_bfd != NULL);
> >  
> > -  if (reloc_entry->address > bfd_get_section_limit (abfd, input_section))
> > +  /* We only use bfd_reloc_offset_in_range for final linking because
> > +     mips object files may use relocations that seem to access beyond
> > +     section limits.  gas/testsuite/gas/mips/dla-reloc.s is an example
> > +     that puts R_MIPS_SUB, a 64-bit relocation, on the last
> > +     instruction in the section.  If final linking that object file
> > +     the R_MIPS_SUB won't be processed here since it applies to the
> > +     addend for the next reloc rather than the section contents.  */
> > +  if (!relocatable
> > +      && !bfd_reloc_offset_in_range (reloc_entry->howto, abfd,
> > +				     input_section, reloc_entry->address))
> >      return bfd_reloc_outofrange;
> 
>  Would a correct check be feasible here?  For a composed relocation only 
> the final entry is applied to output, so could we instead check if there 
> is a follow-up relocation?

I don't think there is any easy and safe way of doing that.  Even
though there is a nice tidy array of NULL terminated arelent pointers,
the special_function doesn't see an arelent** but rather an arelent*.

Hmm, how about replacing !relocatable above with
!(relocatable && !reloc_entry->howto->partial_inplace) ie. the
condition under which _bfd_mips_elf_generic_reloc writes section
contents?

-- 
Alan Modra
Australia Development Lab, IBM