This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: PR binutils/3826: elf_object_p can't tell freebsd object file from standard ELF object file
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Tue, 13 Mar 2007 12:01:15 +0100
- Subject: Re: PATCH: PR binutils/3826: elf_object_p can't tell freebsd object file from standard ELF object file
- References: <20070104153132.GA24896@lucon.org> <20070104194750.GA30044@lucon.org> <20070105032945.GD12887@bubble.grove.modra.org> <20070105035443.GA32376@lucon.org> <20070105043825.GF12887@bubble.grove.modra.org> <20070105051240.GA4227@lucon.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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