public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Alan Modra <amodra@gmail.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: binutils testsuite pr21231b
Date: Mon, 10 Apr 2017 15:57:00 -0000	[thread overview]
Message-ID: <CAMe9rOqHxO2LYPwLt3JUNDWyyoriPDCzm=QsfHcGLvn_rxJm+g@mail.gmail.com> (raw)
In-Reply-To: <20170410041529.GB16711@bubble.grove.modra.org>

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

On Sun, Apr 9, 2017 at 9:15 PM, Alan Modra <amodra@gmail.com> wrote:
> HJ,
> This test is failing on x86_64-linux with --enable-targets=all.
>
> ../gas/as-new ~/src/binutils-gdb/binutils/testsuite/binutils-all/i386/pr21231b.s --32 -o tmpdir/i386temp.o
> ./objcopy   tmpdir/i386temp.o  tmpdir/i386copy.o
> ./objcopy: warning: tmpdir/i386temp.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
>
> ./objcopy: warning: tmpdir/i386temp.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000001
>
> echo $?
> 0
>
> The problem is that the warning is being emitted during object
> recognition.
>
> #0  _bfd_elf_parse_gnu_properties (abfd=abfd@entry=0xc91f40, note=note@entry=0x7fffffffd620) at /home/alan/src/binutils-gdb/bfd/elf-properties.c:171
> #1  0x0000000000446bed in elfobj_grok_gnu_note (note=0x7fffffffd620, abfd=0xc91f40) at /home/alan/src/binutils-gdb/bfd/elf.c:9757
> #2  elf_parse_notes (abfd=abfd@entry=0xc91f40, buf=0xca29e0 "\004", size=60, offset=52) at /home/alan/src/binutils-gdb/bfd/elf.c:10893
> #3  0x000000000044a8a8 in _bfd_elf_make_section_from_shdr (abfd=0xc91f40, hdr=0xc92e68, name=<optimised out>, shindex=<optimised out>) at /home/alan/src/binutils-gdb/bfd/elf.c:1065
> #4  0x00000000004491f1 in bfd_section_from_shdr (abfd=abfd@entry=0xc91f40, shindex=shindex@entry=4) at /home/alan/src/binutils-gdb/bfd/elf.c:2503
> #5  0x000000000048312b in bfd_elf32_object_p (abfd=0xc91f40) at /home/alan/src/binutils-gdb/bfd/elfcode.h:804
> #6  0x000000000042e7af in bfd_check_format_matches (abfd=abfd@entry=0xc91f40, format=format@entry=bfd_object, matching=matching@entry=0x7fffffffda98) at /home/alan/src/binutils-gdb/bfd/format.c:311
>
> At this point, we are checking
>  p abfd->xvec
> $2 = (const struct bfd_target *) 0x826b00 <elf32_le_vec>
>
> That's the generic ELF target, with no bed->parse_gnu_properties.
> You can't emit errors/warnings in _bfd_elf_parse_gnu_properties except
> for those that will occur for all targets.  Please fix.
>

Here is a patch to make generic ELF target vectors the last resort.

-- 
H.J.

[-- Attachment #2: 0001-Place-generic-ELF-target-vectors-at-the-end.patch --]
[-- Type: text/x-patch, Size: 2105 bytes --]

From 406abf9f7be65d98724b171d7d95413a88636b32 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Mon, 10 Apr 2017 08:51:36 -0700
Subject: [PATCH] Place generic ELF target vectors at the end

Generic ELF target vectors are included in BFD so that objdump or gdb
are be able to examine the file even if we don't recognize the ELF
machine type.  They should be placed after all other ELF target vectors
and used as the last resort so that the ELF target vector with matching
machine type is selected if possible.

	* targets.c (_bfd_target_vector): Move generic ELF target vectors
	after all other ELF target vectors.
---
 bfd/targets.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/bfd/targets.c b/bfd/targets.c
index 5841e8d..c2df84a 100644
--- a/bfd/targets.c
+++ b/bfd/targets.c
@@ -1046,17 +1046,6 @@ static const bfd_target * const _bfd_target_vector[] =
 
 	&dlx_elf32_be_vec,
 
-	/* This, and other vectors, may not be used in any *.mt configuration.
-	   But that does not mean they are unnecessary.  If configured with
-	   --enable-targets=all, objdump or gdb should be able to examine
-	   the file even if we don't recognize the machine type.  */
-	&elf32_be_vec,
-	&elf32_le_vec,
-#ifdef BFD64
-	&elf64_be_vec,
-	&elf64_le_vec,
-#endif
-
 	&epiphany_elf32_vec,
 
 	&fr30_elf32_vec,
@@ -1455,6 +1444,20 @@ static const bfd_target * const _bfd_target_vector[] =
 	&z80_coff_vec,
 
 	&z8k_coff_vec,
+
+	/* These generic ELF vectors may not be used in any *.mt
+	   configuration.  But that does not mean they are unnecessary.
+	   If configured with --enable-targets=all, objdump or gdb
+	   should be able to examine the file even if we don't recognize
+	   the machine type.  They should be placed after all other ELF
+	   vectors and used as the last resort so that the ELF vector
+	   with matching machine type is selected if possible.  */
+	&elf32_be_vec,
+	&elf32_le_vec,
+#ifdef BFD64
+	&elf64_be_vec,
+	&elf64_le_vec,
+#endif
 #endif /* not SELECT_VECS */
 
 /* Always support S-records, for convenience.  */
-- 
2.9.3


  reply	other threads:[~2017-04-10 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  4:15 Alan Modra
2017-04-10 15:57 ` H.J. Lu [this message]
2017-04-10 23:51   ` Alan Modra
2017-04-11  0:08     ` H.J. Lu
2017-04-11 16:07       ` H.J. Lu
2017-04-11 21:49         ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOqHxO2LYPwLt3JUNDWyyoriPDCzm=QsfHcGLvn_rxJm+g@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).