bfd_arch_get_compatible

[H.J. Lu]

On Sun, Jun 5, 2011 at 6:25 PM, Alan Modra <amodra@gmail.com> wrote:
> On Sat, Jun 04, 2011 at 10:59:50AM -0700, H.J. Lu wrote:
>> elf_object_p change caused:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12842
>
> It was more the case that my change exposed other bugs, but, yes the
> patch was half-baked and insufficiently tested.  I did test
> i686-linux, i586-aout, i686-pe and powerpc-linux and saw no problem.
>
>> Do you have a testcase to show the bug you tried to fix?
>
> Yes, -b is ignored when selecting EM_NONE (and in some cases
> ELFOSABI_NONE) targets.  eg.
>
> $ objdump -b elf32-little gas/as.o -h
>
> gas/as.o:     file format elf32-i386
>                          ^^^^^^^^^^
> Forcing a generic target isn't something you would usually want to do,
> but I found a use in combination with --accept-unknown-input-arch.
>
> The underlying problem is that elf_object_p rejects the generic
> targets when BFD is compiled with support for a more specific target,
> in order to not match multiple targets in bfd_check_format_matches,
> which then returns an error.  This is course was just a hack.  What we
> should have done is taught bfd_check_format_matches that multiple
> matches are OK when the matches in question are generic ELF and more
> specific ELF targets.  I could have done that without adding another
> field to bfd_target, but that would require treating ELF targets
> specially in bfd_check_format_matches, as much of a hack as the
> elf_object_p hack.
>
>        * targets.c (bfd_target): Make ar_max_namelen an unsigned char.
>        Add match_priority.
>        * configure.in: Bump bfd version.
>        * elfcode.h (elf_object_p): Delete hacks preventing match of
>        EM_NONE and ELFOSABI_NONE targets when a better match exists.

Will the ELFOSABI_NONE change may break actual usages,
like linking ELFOSABI_FREEBSD with ELFOSABI_NONE
to generate ELFOSABI_NONE and vice verse?


-- 
H.J.