Undefined pcodeops
Closed this issue · 6 comments
The pcodeops in the eecore.sinc aren't actually doing anything as they aren't defined in the java lib. There is information on how to do so at the bottom of mips.sinc
I will put in a PR later today after class and we can merge the work we have done.
https://github.com/astrelsky/ghidra_MIPSR5900
You're correct @astrelsky. Implementing the pcodeops is pretty low priority for me, they appear in the decompilation view as function calls - which is mostly fine.
I would welcome a PR that implements some of them. It would be interesting to see if there is any improvement in the decompilation output :)
The main problem with leaving them unimplemented is that the decompiler doesn't know what to do with the pcodeop and doesn't propegate the data in the registers. I have all of the mmi instructions written out in sleigh. I just have to check how you have the registers setup before I can submit a pr.
I was killing myself over writing these out as I didn't know someone was already doing this. After the merge I'm going to delete my repo.
Cool. Does it make a big difference to the decompilation? I was thinking it might make it quite messy?
Watch out for some of the special cases I added, particularly PADDUB
with a zero operand - which only works on 64 bit registers because 128 bit constant varnodes are not supported and you get a really ugly decompilation otherwise.
I'm going to have a handful of commits in the pr. Just a few things here and there such as the 64 bit representations of the 128 bit registers were big endian instead of little.
The parallel instructions can be a little messy considering what they do. For the most part it isn't to bad.
Did you ever have an issue with noreturn analysis?
Also are you sure about the parameter passing? I'm pretty sure ee only passes a0-a3 and none of the temporary registers are preserved. I am uncertain about the fp registers but I was under the assumption only f12-f14 are passed. Also I know that v0 and v1 are a pair of outputs along with f0, f1.
I think the arguments are correct - at least for the standard, it depends on the compiler of course. Generally, I don’t think you ever need a pair v0,v1 for return because they are 128 bit already, of course if there are 256 bit returns you would. I’m far from an expert in the processor, a lot of the info comes from reverse engineering some light gun games in IDA and talking with the DobieStation guys.
I found some information regarding this here https://assemblergames.com/threads/ps2-calling-convention.70886/
The only instructions that can access the full 128 bit registers are the mmi instructions. The gcc compilers for the emotion engine actually won't pass the full 128 bit register. Either way I believe that the v0, v1 return values are not a pair, but actually for more than one return value. I'm not sure if gcc would do this or if it would only be convention for those programming directly with mips.