Re: relocs_compatible hook considered harmful

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Apr 24, 2008 at 02:11:48PM +0930, Alan Modra wrote:
> On Wed, Apr 23, 2008 at 10:09:15PM -0400, Daniel Jacobowitz wrote:
> > Still... if a file is incompatible enough that we can't check its
> > relocs, why're we telling the backend to process them anyway?
> 
> It boils down to whether an input file passes the particular backend
> bfd_check_format_matches.  For ELF, this is elf_object_p.  If a
> backend needs further restrictions for some reason, I guess it could
> implement elf_backend_object_p.

Right, I already do, but that's the wrong backend.  I'm having
problems on my local tree but you should be able to see the same
problem with blackfin or frv.  We've got two pretty much incompatible
object formats:

#define IS_FDPIC(bfd) ((bfd)->xvec == &bfd_elf32_frvfdpic_vec)

static bfd_boolean
elf32_frv_object_p (abfd)
     bfd *abfd;
{
  bfd_default_set_arch_mach (abfd, bfd_arch_frv, elf32_frv_machine
  (abfd));
  return (((elf_elfheader (abfd)->e_flags & EF_FRV_FDPIC) != 0)
          == (IS_FDPIC (abfd)));
}

So I ran ld by hand and forgot to select the FDPIC emulation.  But
the inputs were FDPIC.  So they're not relocs_compatible_p because
they have different emulations.  But they're both ELF objects and
they have the same machine number and so forth.

So check_relocs is never called for any of the input files.  Nothing
creates the GOT section.  But we get to relocate_section, find an
R_SH_GOT32, trigger an assertion, and then crash.

Maybe I should just make the error in merge_private_data fatal?

-- 
Daniel Jacobowitz
CodeSourcery