bug-binutils
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]