[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/29764] New: objdump confused with --enable-targets=all if
From: |
clyon at gcc dot gnu.org |
Subject: |
[Bug binutils/29764] New: objdump confused with --enable-targets=all if several machines include the same cpu name |
Date: |
Wed, 09 Nov 2022 10:07:27 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=29764
Bug ID: 29764
Summary: objdump confused with --enable-targets=all if several
machines include the same cpu name
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed this problem while looking at Sourceware's buildbot for armhf
(https://builder.sourceware.org/buildbot/#/builders/binutils-debian-armhf)
which builds natively on arm-none-linux-gnueabihf with --enable-targets=all,
you can see two failures:
FAIL: Assemble and dump for cortex-a76ae CPU
FAIL: Assemble and dump for cortex-a77 CPU
which happen because objdump complains with:
objdump: can't disassemble for architecture aarch64
Here is what happens:
- objdump is called with -d -mcortex-a76ae, so in disassemble_data(), we have
machine != NULL and we call bsd_scan_arch (machine) (where machine ==
"cortex-a76ae")
- thanks to --enable-targets=all, bfd_archures_list starts with the aarch64
one, which does contain an entry for cortex-a76ae, so we populate
abfd->arch_info with this aarch64 entry
- then we call disassembler(), which returns 0, because ARCH_aarch64 is NOT
defined (because we didn't configure with --enable-64-bit-bfd
- thus we emit the error message mentioned above
If we configure with --enable-64-bit-bfd, disassemble() no longer returns 0, so
disassembly "succeeds" but produces:
0: e320f000 .inst 0xe320f000 ; undefined
The test PASSes, but only because the output is ignored
If we do not use --enable-targets=all, then we only scan the "arm"
architecture, and find the right match, and the test succeeds as expected.
In short, the problem occurs because aarch64 and arm share some processor
names. In theory this could happen with other targets (eg. if mips has a
processor with the same name as sparc)
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug binutils/29764] New: objdump confused with --enable-targets=all if several machines include the same cpu name,
clyon at gcc dot gnu.org <=
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, sam at gentoo dot org, 2022/11/10
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, nickc at redhat dot com, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, nickc at redhat dot com, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, clyon at gcc dot gnu.org, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, nickc at redhat dot com, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, clyon at gcc dot gnu.org, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, cvs-commit at gcc dot gnu.org, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, nickc at redhat dot com, 2022/11/21
- [Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name, clyon at gcc dot gnu.org, 2022/11/21