PATCH: PR binutils/3826: elf_object_p can't tell freebsd object file from standard ELF object file

[Jakub Jelinek]

On Thu, Jan 04, 2007 at 09:12:40PM -0800, H. J. Lu wrote:
> On Fri, Jan 05, 2007 at 03:08:25PM +1030, Alan Modra wrote:
> > > 
> > > That is enirely reasonable to reject such object file since it may
> > > contain info we don't know how to handle properly. If we can handle
> > 
> > I disagree.  We ought to try our best to handle an object file with
> > an unexpected OSABI, particularly if the unexpected value is
> > ELFOSABI_NONE.
> > 
> 
> It is the other way around.  GNU linker can handle ELFOSABI_NONE. I
> believe it is OK to reject an ELF file with an unexpected OSABI, which
> isn't ELFOSABI_NONE, and we don't know how to handle it properly.

Your patch breaks e.g. MadWifi build on Linux - there is no point
why Linux binutils should include freebsd vecs and with the strict
checking of EI_OSABI you added in your patch you disallow != ELFOSABI_NONE
marked input files which can be perfectly handled by elf_i386.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230964

If you really want you could hack up check_format_matches and elf_object_p
so that if osabi doesn't match, but bed has osabi ELFOSABI_NONE, it would
use the target only if there are no other matches (similarly how it
ATM handles bfd_error_file_ambiguously_recognized for archives).
In any case the osabi check should go into elf_object_p (
if (get_elf_backend_data (abfd)->elf_osabi != ELFOSABI_NONE
    && i_ehdrp->e_ident[EI_OSABI] == get_elf_backend_data (abfd)->elf_osabi)
  goto got_ambiguously_recognized_error;
), the way you wrote it in your patch means you only check it on
elf32-i386.c and elf32-i370.c and no other target (because all other targets
that ever redefine ELF_OSABI have their own elf_backend_object_p macros).

	Jakub