This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bfd_arch_get_compatible


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]