This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [Patch] sh64: Fix gas testsuite expected output
- From: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- To: hp at bitrange dot com
- Cc: binutils at sources dot redhat dot com
- Date: Tue, 22 Oct 2002 17:21:38 +0900
- Subject: Re: [Patch] sh64: Fix gas testsuite expected output
- References: <Pine.BSF.4.44.0210181511340.59689-100000@dair.pair.com>
Hans-Peter Nilsson <hp@bitrange.com> wrote:
> Suggestion: for REL (still meaning unlinked) objects have an
> empty section with a special name (keyed on machine-name and
> vendor name, like GNU as in GNU binutils, and on function) in
> each unlinked object, e.g.
> .SH.GNU.abi.gnulinux
> .SH.GNU.abi.standalone
> .SH.GNU.abi.netbsd
> (Names TBD; just examples.) Caveat: it doesn't solve the
> ambiguity for existing objects. I think we can live with that,
> if objects without such a section are treated as compatible with
> whatever context they are used in. This should keep backward
> compatibility, and above all, old tools won't hork when they see
> "new" objects.
I looked the original problem again. I got "File format is ambiguous"
messages when running gas testsuite for the sh4-unknown-linux-gnu
target configured with --enable-targets=all, but the error occurs
only for the big endian objects.
I found that bfd/format.c:bfd_check_format_matches doesn't fail when
the default vector is an element of the set of matching vectors. And
all FAILs are gone when changing bfd_check_format_matches so as to
permit also the alternative vector of the default one.
For sh64-unknown-linux-gnu, I got 37 unexpected failures after this
change. In these cases, bfd_check_format_matches failed for 64-bit
objects because the default format of sh64-unknown-linux-gnu target
is 32-bit elf32-sh64-linux format but matching formats are 64-bit
formats.
So I guess that the ambiguity for existing objects can be handled by
adding something to bfd_check_format_matches which selects an appropriate
representative vector from the ambiguity set if possible, as it was
already done when the default vector is included in this set.
Thoughts?
Regards,
kaz