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.