-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacOS Classic - Analyze dataflow and preserved registers #573
Comments
Not having had time to look at this closely yet, my first suspicion is that Reko is not correctly handling the sequence:
causing it to consider the stack to be unbalanced, which in forces it to consider the register assignments as generating output values, rather than restoring the registers to the values they had on entry to the procedure. |
@uxmal looking at it further, it appears to me that it might be having problems with the call to ZEROBUFFER. it's pushing a ptr to A5World - word32 buffer size at (a4), then pushing word32 buffer size at (a4), then calls procedure ZEROBUFFER. The procedure ZEROBUFFER is interesting in that it pulls the return address and puts it in a0, and then pulls the size/length of the buffer , then the address of the buffer. Then clears the buffer and returns via jmp.l (a0). The RTL code generated is a call to a0 and then return. Probably should be a seperate question (issue). Looking at RTL code the setup of parameters prior to calling the procedure ZERROBUFFER, there is reference to a5 which is the A5World pointer address. While previously your talked about a structure that points to A5World. The actual pointer to A5World should be an offset from the start of A5World memory region that points to the A5World zero offset address. This pointer would then be used for all offsets relative to the A5World that are being referenced. Assembly section from _DATAINIT RTL code for above assembly |
Indeed, the |
I'm going to have to look closer at this tomorrow. It's curious that this has regressed since none of the logic in the data flow analysis "should" affect the symbol generation which happens much earlier in the decompilation process. |
Looking at how some of the procedures that get defined after Analyze Dataflow, it appears to me that some of registers that are being pushed at the begining and pulled at the end of the procedure are being included in the procedure signature. Should the registers being push at the begining and later pulled prior to exiting, be listed in the preserved registers for the procedure after Analyze dataflow has completed.
Pre Analyze Dataflow
Entry code pushing registers to stack
void _DATAINIT()
{
_DATAINIT_entry:
l0010FC02:
a7 = fp
a5 = a5world
a7 = a7 - 0x04
Mem0[a7:word32] = a4
a7 = a7 - 0x04
Mem0[a7:word32] = a3
a7 = a7 - 0x04
Mem0[a7:word32] = a2
a7 = a7 - 0x04
Mem0[a7:word32] = a1
a7 = a7 - 0x04
Mem0[a7:word32] = a0
a7 = a7 - 0x04
Mem0[a7:word32] = d7
a7 = a7 - 0x04
Mem0[a7:word32] = d6
a7 = a7 - 0x04
Mem0[a7:word32] = d5
a7 = a7 - 0x04
Mem0[a7:word32] = d4
a7 = a7 - 0x04
Mem0[a7:word32] = d3
a7 = a7 - 0x04
Mem0[a7:word32] = d2
a7 = a7 - 0x04
Mem0[a7:word32] = d1
=> Procedure processing
Exit code pulling registers from stack
l0010FC48:
d1 = Mem0[a7:word32]
a7 = a7 + 0x04
d2 = Mem0[a7:word32]
a7 = a7 + 0x04
d3 = Mem0[a7:word32]
a7 = a7 + 0x04
d4 = Mem0[a7:word32]
a7 = a7 + 0x04
d5 = Mem0[a7:word32]
a7 = a7 + 0x04
d6 = Mem0[a7:word32]
a7 = a7 + 0x04
d7 = Mem0[a7:word32]
a7 = a7 + 0x04
a0 = Mem0[a7:word32]
a7 = a7 + 0x04
a1 = Mem0[a7:word32]
a7 = a7 + 0x04
a2 = Mem0[a7:word32]
a7 = a7 + 0x04
a3 = Mem0[a7:word32]
a7 = a7 + 0x04
a4 = Mem0[a7:word32]
a7 = a7 + 0x04
return
_DATAINIT_exit:
}
Exit code pulling registers from stack
Post Analyze dataflow
word32 _DATAINIT(word32 d0, word32 d1, word32 a4, ptr32 & d1Out, ptr32 & d7Out, ptr32 & a3Out, ptr32 & a4Out)
{
_DATAINIT_entry:
l0010FC02:
word32 d0_121
word32 a7_120 = fp - 0x0030
branch Mem0[0x0010FDB4:word16] == 0x01 l0010FC16
l0010FC12:
d0_121 = -0x01
goto l0010FC48
l0010FC16:
word32 a3_88 = a5world - Mem0[0x0010FDB0:word32]
ZEROBUFFER(d1, dwLoc3C, Mem0[0x0010FDB0:word32], a3_88)
Mem101[fp - 0x3C:word32] = 0x0010FDB0 + Mem0[0x0010FDB8:word32]
Mem104[fp - 0x40:word32] = a3_88
uncompress_world(dwArg00, dwArg04)
Mem111[fp - 0x3C:word32] = 0x0010FDB0 + Mem104[0x0010FDBC:word32]
Mem114[fp - 0x40:word32] = a3_88
Mem117[fp - 0x44:word32] = a5world
relocate_world(dwArg00, dwArg04, dwArg08)
a7_120 = fp - 0x38
d0_121 = 0x00
l0010FC48:
word32 a7_56 = a7_120 + 0x04
word32 d1_55
*d1Out = Mem0[a7_120:word32]
word32 d7_67
*d7Out = Mem0[a7_56 + 0x0014:word32]
word32 a3_75
*a3Out = Mem0[a7_56 + 0x0024:word32]
word32 a4_77
*a4Out = Mem0[a7_56 + 0x0028:word32]
return d0_121
_DATAINIT_exit:
}
The text was updated successfully, but these errors were encountered: