aldelaro5 / ghidra-gekko-broadway-lang Goto Github PK

The README states:

consider setting the GQR values so it can properly assume their contents as most games will set them without changing them after

I'm not exactly sure how to go about doing this? Some brief guidance for how to do this in Ghidra would be much appreciated.

i wanted to look at ghidra using a binary i knew 100% what it did and what was what, so i threw my loader from priiloader in it.
to my surprise it wasn't able to disassemble all the asm.

ive included a zip with the binary, the map & .s generated by gcc.
loader.zip

when i reached the main function ( @ 0x58C ) , and pressed D to disassemble it seems to not be able to disassemble the first instruction ( 0x2C030000 : cmpwi r3, 0 ), all the rest seems ok.
weirdly enough it recognizes a cmpwi r4, 0 (0x2E040000 @ 0x5A0 ) later on correctly...?

from what i quickly saw online this seems to be something the cpu language has to fix, but if im wrong go ahead and scold at me. this is the first thing i have ever done in ghidra haha

i've also verified with shell-storm.org that the data is ok :
http://shell-storm.org/online/Online-Assembler-and-Disassembler/?opcodes=2C+03+00+00%0D%0A4D+82+00+20+%0D%0A94+21+FF+E8+%0D%0A7D+80+00+26&arch=ppc64&endianness=big&dis_with_addr=True&dis_with_raw=True&dis_with_ins=True#disassembly

has been an issue for a long time,

but ghidra often emits fneg as (ulonglong)(double)fVar1 & 0x7FFFFFFFFFFFFFFF | ~(ulonglong)(double)fVar1 & 0x800000000000) which is just annoying

Hi,

I'm not sure if this is normal, my mistake, an issue with the lang def or an issue with Ghidra but I've been having some problems getting certain array accesses to look right in the decompiler.

In the original code these would look something like "animRules[iVar21].bulFlag", etc.

Some arrays work fine.

Am I doing something wrong with these arrays or is something wrong with Ghidra or the lang def? Maybe this is normal and I'm just an idiot?

8-byte function parameters can be passed split into two registers, rather than on the stack as this currently does. However, it seems only "odd-even pairs" can do this - a value can be split across e.g. r3 and r4, or r5 and r6, but not r4 and r5. (For examples, see the OSSetAlarm and InsertAlarm functions)

I tried to implement this change in the cspec file, similar to the way the 8-byte output is defined, but was unsuccessful - for example, a function with parameters (u32, u64, u32) will have the u32 in r3, then the u64 in r3 and r4.

This may be a Ghidra limitation - the cspec documentation states:

The first <pentry> from the resource list that fits the datatype and hasn't
been fully used by previous datatypes is assigned to that datatype.

As r4 should be left unused in this case, that seems like it may be impossible to fix without a change to Ghidra.