search

beardypig / ghidra-emotionengine

Ghidra Processor for the Play Station 2's Emotion Engine MIPS based CPU
Apache License 2.0
200 stars 34 forks source link

Fixed issue where unsigned values were displayed as signed #55

Closed Tupelov closed 3 years ago

Tupelov commented 3 years ago

Closes #55

Tupelov commented 3 years ago

I may have messed up the decompilation output. image

Tupelov commented 3 years ago

movie_draw makes perfect sense under this context and i've noticed that pointers now appear 0x10000 off inside the decompilation window when addiu is used to load them

Tupelov commented 3 years ago

Very weird though, because it looks like the instruction is loading the right place but the data is off by 0x10000, I've noticed this with function pointers as well. Maybe its me? I'm not sure

Tupelov commented 3 years ago

Might be a seperate issue as well

Tupelov commented 3 years ago

Doing this fixed it in all the places I've checked but it doesn't sit with me well. image

Tupelov commented 3 years ago

I checked out lui in another project and it seemed fine so it's probably just me then. Still I think testing should be done just to be absolutely sure

Tupelov commented 3 years ago

Tested it out with a different version of the same game and it seem to be and SMT Nocturne specific issue somehow

Tupelov commented 3 years ago

But it doesn't affect the other game I tested Persona 3 FES

Tupelov commented 3 years ago

Ok so the weirdness was accidently making it unsigned when it was signed.

astrelsky commented 3 years ago

Don't worry about the failed checks. This was a mistake on my end and they only failed because I canceled them. The checks are for the java code so it isn't applicable here.

May you please squash the commits? nvm

JayFoxRox commented 3 years ago

This PR was broken (as already described in #53 and #63)

i've noticed that pointers now appear 0x10000 off inside the decompilation window when addiu is used to load them

Here's an example which shows how such a problem can occur.

Here is the corrected disassembly:

ff 01 04 3c        lui        a0,0x1ff
00 00 84 24        _addiu     a0,a0,0x0
65 00 05 24        li         a1,0x65
01 00 06 3c        lui        a2,0x1
00 00 c6 24        addiu      a2,a2,0x0
00 f0 c6 24        addiu      a2,a2,0xfffff000 // This PR turned this into 0xF000 (which is incorrect)
db 76 10 0c        jal        memset
00 00 00 00        nop

Should be:

uint32_t a0 = 0x1FF0000 + 0; // = 0x1FF0000
uint32_t a1 = 'A';
uint32_t a2 = 0x10000 + 0x0 - 0x1000; // = 0xF000
memset(a0, a1, a2);

Which is memset(&_stack, 'A', _stack_size);

With the code from this PR it becomes this broken piece; memset(&_stack, 'A', 0x1f000); (off by 0x10000):

uint32_t a0 = 0x1FF0000 + 0; // = 0x1FF0000
uint32_t a1 = 'A';
uint32_t a2 = 0x10000 + 0x0 + 0xF000; // = 0x1F000
memset(a0, a1, a2);