Open Schala opened 1 year ago
This seems like it's due to the way classic Mac OS on PowerPC uses transition vectors (see https://vintageapple.org/inside_r/pdf/PPC_System_Software_1994.pdf, page 1-27, for more details). It would be nice if Ghidra handled this more cleanly -- for example, in a library, automatically naming each decompiled function after the tvect entry that leads to it.
Describe the bug When decompiling a Macintosh PowerPC binary with function pointer calls, the result, in place , seems bugged. Deleting the function, leaving the subroutine label, is a sort of helpful workaround in that I can at least see the arguments passed, but Ghidra likes to recreate the broken function on every load.
For example, from the Metrowerks CodeWarrior standard C library, there's the __exit function in CodeWarrior version 8.0, in Metrowerks CodeWarrior 8.0/MSL/MSL_C/MSL_Common/Src/abort_exit.c:
Here is the same exit function in a decompiled binary, using the default analysis options plus scalar operand references. As you can see, the calls to the console_exit and __atexit_funcs[--__atexit_curr_func] function pointers are decompiled to FUN_1002077c, which contains a code calling error from the r12 register:
To Reproduce Steps to reproduce the behavior:
Expected behavior As seen in Win32/64 binaries, for instance, the decompiled code should produce a line of code similar to
(*PTR_DAT_12345678)(foo, bar)
for example.Environment (please complete the following information):