TOC/OPD/GOT/etc. is not processed in ELFs using PPC64 with 32-bit addressing

Describe the bug Take any ELF64 file using PowerPC64 and 32-bit addressing. I was using “PowerISA-Altivec-64-32addr”, but any PPC64 language with 32-bit addressing will suffice.

This is handled by `PowerPC64_ElfExtension". It satisfies this check:

https://github.com/NationalSecurityAgency/ghidra/blob/49c2010b63b56c8f20845f3970fedd95d003b1e9/Ghidra/Processors/PowerPC/src/main/java/ghidra/app/util/bin/format/elf/extend/PowerPC64_ElfExtension.java#L55

However when processElf is called then this check is included:

https://github.com/NationalSecurityAgency/ghidra/blob/49c2010b63b56c8f20845f3970fedd95d003b1e9/Ghidra/Processors/PowerPC/src/main/java/ghidra/app/util/bin/format/elf/extend/PowerPC64_ElfExtension.java#L63

Which fails since it is equal to 32.

This may just be an unimplemented feature (I would need to see what assumptions the class makes), but we can clearly see that files imported using this PPC variation are not properly processed.

To Reproduce Steps to reproduce the behavior:

1. Take any ELF file satisfying the aforementioned description. I used a PS3 EBOOT file.
2. Analyse this file.
3. Note how the TOC_BASE symbol is never created and how r2 is not set at all in any function.

Environment (please complete the following information):

• OS: Windows 10 Education 1809
• Java Version: 12
• Ghidra Version: 9.0.2

[VelocityRa]

Update: @aerosoul94 discovered that if r2 is added to the <unaffected> list here: https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Processors/PowerPC/data/languages/ppc_64_32.cspec#L96 then the decompiler issue with it is fixed. Here’s a comparison:

Left is before the fix, right is after. Look specifically at the TOC-relative string references that are resolved after the fix. (right is also on 9.2, but it doesn’t matter, 9.1.2 is fixed with this too)

Let me know if you need anything else.

[aerosoul94]

I’ve made bold what is most relevant to this issue but here are PS3 (PPU) ABI changes for reference:

This appendix identifies the primary differences between the PPU ABI for Cell OS Lv-2 and the 64-bit PowerPC ELF ABI. • The size and alignment of a pointer are each 4 bytes. The PowerPC ABI defines these as 8 bytes. • The size and alignment of long are each 4 bytes. The PowerPC ABI defines these as 8 bytes. • The “plain” char type is signed char whereas the plain char type is an unsigned char in the PowerPC ABI. • Additional data types have been defined to represent some fundamental data types for OS and library interfaces. (See Table 2.) • Each function descriptor has two 32-bit address fields and no environment pointer. As a result, this ABI does not support nested functions. Nested functions are a GCC language extension. For the PowerPC ABI, each function descriptor consists of three 64-bit address fields: the address of the function body, a pointer to the TOC referred to by the function, and the environment pointer used by the function. • The initial values of some registers have been changed, for process initialization. • New relocation types, R_PPC64_TOC32, R_PPC64_DTPMOD32, R_PPC64_TPREL32 and R_PPC64_DPTPREL32 are defined. • The OS and ABI identifier in the ELF file header is defined as 102 for Cell OS Lv-2. • VRSAVE is not required to be updated at runtime; however, it should be initialized to 0xffff_ffff. • Traceback tables are not supported. • The “extended precision” format is not supported.

Relocations are handled differently as well (note the use of patchseg and symseg): https://github.com/aerosoul94/ida_gel/blob/master/src/ps3/cell_loader.cpp#L334

OPD section recovery is likely necessary because they strip sections (or maybe just section names actually) for retail binaries.

@Bo98 A workaround would be taking the TOC from the function descriptor, then setting the r2 register value for that function.