Rebaccus VC Crash Explanation

Here's the Ocarina of Time VC JP decompile of the same CPU function for reference. MM's VC is very similar.
https://github.com/zeldaret/oot-vc/blob/master/src/virtual_console/cpu.c#L5326C5-L5353C6

The proposed fix I have in MMR's VC: In cpuExecuteCall, have cpuExecuteUpdate run before FindExternalCall marks a JAL as repointered (to prevent cpuExecuteUpdate's code cleanup from discovering this JAL prematurely).


Emulated JALs do a few things, they'll write to the emulated CPU some status stuff, and then there will be the branch it takes which can self-modify.

Normal dynarec jump assembly behaviour while a JAL is interpreter:
lis r5, N64Address@h
ori r5, r5, N64Address@l
stw r5, N64regs[RA](CPU) (this gets overwritten with the real return address by cpuExecuteCall)
bl cpuExecuteCallWrapper (backs up dedicated PPCtoN64 registers before going into cpuExecuteCall)

After running cpuExecuteCall, when it's pointing to recompiled code:
lis r5, ThisCallersReturnAddr@h
ori r5, r5, ThisCallersReturnAddr@l
stw r5, N64regs[RA](CPU)
bl RecompiledCodeTarget


cpuExecuteCall will tag the JAL in a list of external calls, then change the lis/ori r5 instructions to the caller's PPC return address. Then it calls cpuExecuteUpdate so some maintenance can happen and to fetch the target recompiled code address, to update the bl instruction.

In the unlucky timing situation, if cpuExecuteUpdate:
think's it's time for code cleanup, and
	- the code cleanup function finds existing recompiled code for the target N64 function, and
	- it's a candidate for deletion (is old enough and no running code is going to return to it),
every repointered external call with this N64 address gets reverted back to interpreter instructions as this recomp code is deleted.
...including any unfinished building ones, like the lis/ori cpuExecuteCall just worked on.
cpuExecuteUpdate continues on to cpuMakeFunction (which rebuilds the target N64 code and returns a pointer for the bl instruction).

Thus turning it into:
lis r5, N64Address@h
oris r5, r5, N64Adress@l
stw r5, N64regs[RA](CPU)
bl RecompiledCodeTarget

...Effectively creating a sort of code landmine. Upon a second run on this now broken JAL, the PPC return address is set wrong. Instead of coming back to the caller, the program counter gets sent to the N64 address... in Wii space. Most of the time it crashes immediately by executing a invalid load/store or illegal instruction. Sometimes it can get caught in an infinite loop which won't hit an exeception.

...There was one crash reported where the broken return address sent the program counter to begin an IOS file seek. A bit concerning.
Here's one of the crash screens shared in the bug report channel with the random crash error present