GDB fails to disassemble PowerPC VLE code
Matthew Hall
matthew.hall@mesol.com.au
Mon May 12 00:40:18 GMT 2025
More information about the Binutils mailing list
Mon May 12 00:40:18 GMT 2025
- Previous message (by thread): [PATCH v3 2/2] RISC-V: Add support for RISC-V Profiles 23.
- Next message (by thread): [PATCH] aarch64: Replace incorrect comment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
I've been having an issue where GDB will allow me to set the architecture to powerpc:vle, and will parrot that architecture back to me with show architecture, however it won't correctly disassemble the VLE code. Instead,, all the 16bit instructions are ignored and replaced with .long and the raw bytes. This issue has been present for a long time; I see it in both the current master and also the GDB 7.8.2 release that's distributed by NXP as part of their PowerPC toolchain.
There seems to be two issues. The first happens during the loading of the ELF in rs6000-tdep.c line 7662, where the assumption is made that anything using SPE extensions should be treated as an e500 core that doesn't support VLE.
if (bfd_uses_spe_extensions (info.abfd))
{
arch = info.bfd_arch_info->arch;
mach = bfd_mach_ppc_e500;
bfd_default_set_arch_mach (&abfd, arch, mach);
info.bfd_arch_info = bfd_get_arch_info (&abfd);
}
The second issue is that even after manually setting the architecture to powerpc:vle the PPC_OPCODE_VLE flag is dropped from the dialect. Line 309 of ppc-dis.c attempts to support mixed projects where some sections are compiled as VLE and others as BookE by reading the flags in the section headers. When I stop here with the debugger my info->section pointer appears to be NULL and the assumption is that all pages are Book E.
/* Disassemble according to the section headers flags for VLE-mode. */
if (dialect & PPC_OPCODE_VLE
&& info->section != NULL && info->section->owner != NULL
&& bfd_get_flavour (info->section->owner) == bfd_target_elf_flavour
&& elf_object_id (info->section->owner) == PPC32_ELF_DATA
&& (elf_section_flags (info->section) & SHF_PPC_VLE) != 0)
return dialect;
else
return dialect & ~ PPC_OPCODE_VLE;
I've attached a patch I'm using to fix this issue. For the BFD mach selection I've changed the logic to look at both SPE and VLE flags to determine the correct mach to use. If only SPE is present bfd_mach_ppc_e500 is chosen, if VLE is present bfd_mach_ppc_vle is chosen. For the disassembly based on section header flags I've added a new branch to manage my situation; if the dialect contains PPC_OPCODE_VLE and the section pointer is invalid I assume the code is VLE instead of falling back to BookE. I figure that most people compiling for the PowerPC e200 cores will either compile their entire project in BookE or VLE. It would be better to work out why that section pointer is NULL in my case, and I may look into it if I find some more time, but for now my patch has kept me moving.
Thanks,
Matthew Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250512/d2052f5b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VLE disassembly.patch
Type: text/x-patch
Size: 5773 bytes
Desc: VLE disassembly.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20250512/d2052f5b/attachment-0001.bin>
- Previous message (by thread): [PATCH v3 2/2] RISC-V: Add support for RISC-V Profiles 23.
- Next message (by thread): [PATCH] aarch64: Replace incorrect comment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list