* binutils testsuite pr21231b
@ 2017-04-10 4:15 Alan Modra
2017-04-10 15:57 ` H.J. Lu
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2017-04-10 4:15 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
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.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils testsuite pr21231b
2017-04-10 4:15 binutils testsuite pr21231b Alan Modra
@ 2017-04-10 15:57 ` H.J. Lu
2017-04-10 23:51 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 2017-04-10 15:57 UTC (permalink / raw)
To: Alan Modra; +Cc: Binutils
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils testsuite pr21231b
2017-04-10 15:57 ` H.J. Lu
@ 2017-04-10 23:51 ` Alan Modra
2017-04-11 0:08 ` H.J. Lu
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2017-04-10 23:51 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
On Mon, Apr 10, 2017 at 08:57:42AM -0700, H.J. Lu wrote:
> On Sun, Apr 9, 2017 at 9:15 PM, Alan Modra <amodra@gmail.com> wrote:
> > 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.
Not a good idea. It sets a bad precedent that the target vector order
can be changed to suit poorly written code. Next thing you'll be
wanting x86_64_elf64_fbsd_vec to sort before x86_64_elf64_vec, or
someone else will want something similar for other targets, and we'll
have breakage if the vector order is changed.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils testsuite pr21231b
2017-04-10 23:51 ` Alan Modra
@ 2017-04-11 0:08 ` H.J. Lu
2017-04-11 16:07 ` H.J. Lu
0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 2017-04-11 0:08 UTC (permalink / raw)
To: Alan Modra; +Cc: Binutils
On Mon, Apr 10, 2017 at 4:51 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 08:57:42AM -0700, H.J. Lu wrote:
>> On Sun, Apr 9, 2017 at 9:15 PM, Alan Modra <amodra@gmail.com> wrote:
>> > 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.
>
> Not a good idea. It sets a bad precedent that the target vector order
> can be changed to suit poorly written code. Next thing you'll be
> wanting x86_64_elf64_fbsd_vec to sort before x86_64_elf64_vec, or
> someone else will want something similar for other targets, and we'll
> have breakage if the vector order is changed.
>
BFD shouldn't try generic target vector before real one and config.bfd
has
# If we support any ELF target, then automatically add support for the
# generic ELF targets. This permits an objdump with some ELF support
# to be used on an arbitrary ELF file for anything other than
# relocation information.
case "${targ_defvec} ${targ_selvecs}" in
*elf64* | *mips_elf32_n*)
targ_selvecs="${targ_selvecs} elf64_le_vec elf64_be_vec
elf32_le_vec elf32_be_vec"
;;
*elf32*)
targ_selvecs="${targ_selvecs} elf32_le_vec elf32_be_vec"
;;
esac
If generic ELF target vectors are moved first, we may run into similar
problems.
As for x86_64_elf64_fbsd_vec vs x86_64_elf64_vec, either there is
already an issue, which we have been living with, or there is no issue
at all.
--
H.J.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils testsuite pr21231b
2017-04-11 0:08 ` H.J. Lu
@ 2017-04-11 16:07 ` H.J. Lu
2017-04-11 21:49 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 2017-04-11 16:07 UTC (permalink / raw)
To: Alan Modra; +Cc: Binutils
[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]
On Mon, Apr 10, 2017 at 5:08 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 4:51 PM, Alan Modra <amodra@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 08:57:42AM -0700, H.J. Lu wrote:
>>> On Sun, Apr 9, 2017 at 9:15 PM, Alan Modra <amodra@gmail.com> wrote:
>>> > 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.
>>
>> Not a good idea. It sets a bad precedent that the target vector order
>> can be changed to suit poorly written code. Next thing you'll be
>> wanting x86_64_elf64_fbsd_vec to sort before x86_64_elf64_vec, or
>> someone else will want something similar for other targets, and we'll
>> have breakage if the vector order is changed.
>>
>
> BFD shouldn't try generic target vector before real one and config.bfd
> has
>
> # If we support any ELF target, then automatically add support for the
> # generic ELF targets. This permits an objdump with some ELF support
> # to be used on an arbitrary ELF file for anything other than
> # relocation information.
> case "${targ_defvec} ${targ_selvecs}" in
> *elf64* | *mips_elf32_n*)
> targ_selvecs="${targ_selvecs} elf64_le_vec elf64_be_vec
> elf32_le_vec elf32_be_vec"
> ;;
> *elf32*)
> targ_selvecs="${targ_selvecs} elf32_le_vec elf32_be_vec"
> ;;
> esac
>
> If generic ELF target vectors are moved first, we may run into similar
> problems.
>
> As for x86_64_elf64_fbsd_vec vs x86_64_elf64_vec, either there is
> already an issue, which we have been living with, or there is no issue
> at all.
>
Here is a patch to skip processor-specific GNU program properties with
generic ELF target vector.
--
H.J.
[-- Attachment #2: 0001-Ignore-processor-specific-GNU-program-properties.patch --]
[-- Type: text/x-patch, Size: 1267 bytes --]
From 4925704145f97d1cc2740cd0365ad02693d7caa7 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Tue, 11 Apr 2017 09:02:26 -0700
Subject: [PATCH] Ignore processor-specific GNU program properties
Skip processor-specific GNU program properties with generic ELF target
vector. They should be handled by the matching ELF target vector.
* elf-properties.c (_bfd_elf_parse_gnu_properties): Ignore
processor-specific properties with generic ELF target vector.
---
bfd/elf-properties.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c
index a0456f8..04ef536 100644
--- a/bfd/elf-properties.c
+++ b/bfd/elf-properties.c
@@ -113,7 +113,15 @@ bad_size:
if (type >= GNU_PROPERTY_LOPROC)
{
- if (type < GNU_PROPERTY_LOUSER && bed->parse_gnu_properties)
+ if (bed->elf_machine_code == EM_NONE)
+ {
+ /* Ignore processor-specific properties with generic ELF
+ target vector. They should be handled by the matching
+ ELF target vector. */
+ goto next;
+ }
+ else if (type < GNU_PROPERTY_LOUSER
+ && bed->parse_gnu_properties)
{
enum elf_property_kind kind
= bed->parse_gnu_properties (abfd, type, ptr, datasz);
--
2.9.3
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils testsuite pr21231b
2017-04-11 16:07 ` H.J. Lu
@ 2017-04-11 21:49 ` Alan Modra
0 siblings, 0 replies; 6+ messages in thread
From: Alan Modra @ 2017-04-11 21:49 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
On Tue, Apr 11, 2017 at 09:06:57AM -0700, H.J. Lu wrote:
> Skip processor-specific GNU program properties with generic ELF target
> vector. They should be handled by the matching ELF target vector.
>
> * elf-properties.c (_bfd_elf_parse_gnu_properties): Ignore
> processor-specific properties with generic ELF target vector.
That's a better hack. OK.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-11 21:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-10 4:15 binutils testsuite pr21231b Alan Modra
2017-04-10 15:57 ` H.J. Lu
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
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).