First, a bit of background on why these registers are needed. PPC is a RISC-like ISA, in that all instructions are of the same size (32 bits) and there is limited space for immediate values (usually 16 bits at most) that you would use for things like addresses. So how do you address more that 16 bits?
One option is to build addresses by 16-bit slices, e.g. ...
According to the code of readelf in the GNU binutils package, the presence of VLE instructions can be found in the p_flags and sh_flags fields with the mask 0x10000000 (see binutils-xxx/include/elf/ppc.h and look for PF_PPC_VLE and SHF_PPC_VLE).
These flags seems to be present at the begining of each section in the ELF format. So, you should look for it.
PS3 (cell) ABI used 64-bit registers but 32-bit pointers. Maybe this sample is from there.
P.S. section names .sceStub.text and .rodata.sceResident definitely point to Sony code (SCE= Sony Computer Entertainment)
The Diaphora tool by Joxean Koret can match functions in binaries with different architectures using multiple algorithms.
You can also always do it manually: make one match using strings or magic numbers used, then follow cross-references to find more matches.
SDA is r13, and it changes very rarely. So finding any assignment to r13 will solve the problem for SDA.
Specifically for the referred example it was
lis r13, 1 # Load Immediate Shifted
addi r13, r13, -0x2BF0 # 0xD410 # Add Immediate
Based on w s 's answer, do the following:
Extract the decompression function from the binary. (On Linux, use dd if=Start.dol bs=1 skip=1292664 count=7364 of=decomp.ppc).
Set the retargetable decompiler to raw machine code, decomp.ppc, file format doesn't matter, power pc, big endian, section address and entry point addess = 0x8013FC58.
With these ...
NIA = CIA + EXTS(LI || 0B00)
The || notation denotes concatenation. So if you take LI
0x6A -> 0b1101010
And add two zeroes:
0b1101010 || 0b00 -> 0b110101000 -> 0x1A8
You get: NIA = 0x100004C8 + 0x1A8 = 10000670
base16 0x480001a9 == base2 1001000000000000000000110101001
chop of 5 upper bits and two lower bits for LI = 000000000000000001101010 = 0x6a
shift left 0x6a by two 0x6a << 2 = 0x1a8
add current instruction Address 0x100004c8 to the result 0x10000670 is the Target Address
since LK = 1 put 0x100004cc in link register
a simple python demo (...
If you can run it in QEMU, you can try connecting to the QEMU's GDB stub. Note that this will provide you the CPU-level view, with the OS kernel included, so it may take some work to get to the app's code.
Disclaimer: I'm not going to create a working code example here, and I did not test this on PowerPC for your specific purpose. YMMV
I could think of two ways of doing that. First will be the manual approach by using some IDAPython magicry to manually force all offsets based on r31 to the stack frame structure. Second (which is the one likely used) is using ...
Regarding the potential bug in IDA:
First of all, you can add references yourself with idaapi.add_cref and idaapi.add_dref IDAPython APIs. This may be done with relatively simple script like this:
predefined_r13 = YOUR_R13_VALUE
for h in idautils.Heads():
dis = idc.GetDisasm(h) #probably there is another way ...
This might be an artifact of compiler optimization. Note the li r4,0x14 instruction - the compiler optimizes your 2*10 calculation and loads the result, 20, into r4 directly. However, doing the calculation would modify some status bits, which the li doesn't, so the compiler tries to do the same modification using crclr, and the optimizer isn't smart enough ...