Unhandled Relocation Type 0x6D (PPC32)

[NWPlayer123]

Describe the bug Loading an ELF file with 0x6D/109 relocations won't be handled

To Reproduce As above, simply need to import an ELF file with those relocations used

Expected behavior It to perform the needed relocation

Screenshots

Attachments Pad.zip

Environment (please complete the following information): Windows 10, Ghidra 9.0.4 stable

openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

Additional context Add any other context about the problem here.

[mumbel]

https://www.nxp.com/docs/en/application-note/PPCEABI.pdf

Looks like ghidra currently supports SVR4 ABI relocations, while R_PPC_EMB_SDA21 is EABI

[NWPlayer123]

yeah, all the instructions in it are just changed from e.g. 00001e10 80 80 00 00 lwz r4,0x0(0) -> 00001e10 80 8d 00 3c lwz r4,0x3c(r13)=>BarrelBits with r13 aka SDA1

[ghidra1]

While attempting to implement support for this relocation type I was puzzled by the relocation addresses within your example which are offset 2-bytes from the start of the corresponding instruction. This seems inconsistent with binutils code and what I would expect for a relocation which affects 3-bytes. I need to understand this unexpected relocation offset.

In addition, your object module example has one relocation instance which refers to an external symbol "__PADFixBits" which can not be fixed-up.

[NWPlayer123]

IDA adds __PADFixBits to extern, as long as it can find the variable/name I'll be happy here's some more test files for you samples2.zip

[shuffle2]

This seems inconsistent with binutils code and what I would expect for a relocation which affects 3-bytes. I need to understand this unexpected relocation offset.

These files were produced by codewarrior circa 2004 for nintendo gamecube. iirc they did not use binutils at the time. The "modern" PPC32 EABI actually defines that target of R_PPC_EMB_SDA21 shall be aligned and instructs filling low21 field with Y || (X + A), where Y is 5bits. The older version states that "since fields can be unaligned, names start with ‘u’" and refers to the field as ulow21. So my guess is metrowerks decided to point the reloc at (X + A) instead of Y.

EF_PPC_EMB in ELF ehdr.e_flags declares the file as EABI. Does ghidra already warn about unknown e_flags? Realistically, systems have overlapping e_flags, and it's often required to do a bit more analysis before deciding the actual target ABI/OS/platform/etc.

[ghidra1]

It appears Ghidra needs additional PowerPC compiler specification (.cspec) files and ELF import opinions to address the variety of PowerPC ABI specs and their differences. The ELF e_flags field can be used by the import opinion mechanism via the 'secondary' value (The MIPS.opinon shows an example of this) to permit a different cspec to be utilized.

[ghidra1]

The CarsGCN.elf file contained within samples2.zip contains many disassembly errors due to unknown instruction patterns. I have searched for a PowerPC processor manual which describes the unsupported instruction encodings but have been unsuccessful. If you can point me to a suitable manual that would be helpful.

[mumbel]

Searching for CarsGCN led to dolphin emulator, so I'm assuming it has all the instructions emulated.

Looking at it in Ghidra, for example f3 e1 00 18, looks to be op=0x3c (60), which dolphin source has as potentially either: andcx or psq_st if I'm reading their table look-ups correctly. Basic grep for either in PowerPC/ has 0 results in Ghidra source.

Hope these help: https://cache.freescale.com/files/product/doc/MPC82XINSET.pdf http://datasheets.chipdb.org/IBM/PowerPC/Gekko/gekko_user_manual.pdf

[NWPlayer123]

@ghidra1: @aldelaro5 made this, it's standard PowerPC with Paired Singles extensions, this adds that functionality https://github.com/aldelaro5/ghidra-gekko-broadway-lang

[delroth]

https://fail0verflow.com/media/files/ppc_750cl.pdf is a non-confidential source (unlike the Gekko manual linked earlier) which describes the Paired Singles extension.