Patch: Check input format against output

[Ian Lance Taylor]

"H . J . Lu" <hjl@lucon.org> writes:

> > This kind of check would normally be handled in the
> > merge_private_bfd_data routine of the output BFD.
> > 
> 
> merge_private_bfd_data is defined as bfd_true for many ELF targets.
> If we put this check into merge_private_bfd_data, we may have to touch
> many ELF files.

True, but that doesn't mean it's the wrong thing to do.  We have to
keep half an eye on the future, after all.

Perhaps there should be a generic elf merge_private_bfd_data routine,
which should be the default in elfxx-target.h, and which should be
called by other ELF files.

> lang_check calls bfd_arch_get_compatible:
> 
> const bfd_arch_info_type *
> bfd_arch_get_compatible (abfd, bbfd)
>      const bfd *abfd;
>      const bfd *bbfd;
> {
>   /* If either architecture is unknown, then all we can do is assume
>      the user knows what he's doing.  */
>   if (abfd->arch_info->arch == bfd_arch_unknown)
>     return bbfd->arch_info;
>   if (bbfd->arch_info->arch == bfd_arch_unknown)
>     return abfd->arch_info;
> 
>   /* Otherwise architecture-specific code has to decide.  */
>   return abfd->arch_info->compatible (abfd->arch_info, bbfd->arch_info);
> }
> 
> If the arch for abfd is not configured in BFD, abfd->arch_info->arch
> will be bfd_arch_unknown.

I guess the problem here is that the bad file got recognized as the
generic ELF target, which is bfd_arch_unknown?

It seems to me that we can catch that case easily enough.  Define a
link_input_bfd routine for elf32-gen.c and elf64-gen.c.  Have that
routine roll over and die.  We're not going to be able to link those
files, since we don't know how to process the relocs.

Ian