(homebrew) Bailing on JIT 11404118, Assertion Failed, Invalid Kernel Call

[ashquarky]

Heya!

I've been getting into homebrew development using wut and decaf, which is great. However, I've encountered what looks like a bug in decaf which seems to root from an if statement. I thought it was weird too.

Basically, the error comes down to the following:

[28:27.426130 warning:w108] Bailing on JIT 11404118 ident due to failed decode at 1140411c
[28:27.426184 critical:w108] Assertion failed:
Expression: kc
File: /home/ash/Apps/decaf-emu/src/libcpu/src/jit/jit_system.cpp
Line: 228
Message: Encountered invalid Kernel Call ID 35782656

Assertion failed:
Expression: kc
File: /home/ash/Apps/decaf-emu/src/libcpu/src/jit/jit_system.cpp
Line: 228
Message: Encountered invalid Kernel Call ID 35782656

(full log)

This is my main loop:

if (frameCounter == 60) {
    frameCounter = 0;
    //stuff here, not really important
    OSReport("[Main]About to run CPU!");
    cyc = run_6502(&ctx, 100); //handwritten PowerPC, calls OSReport before jumping back
    OSReport("[Main]CPU Returned! a:0x%02X p:0x%02X 0x20:0x%02X 0x21:0x%02X 0x22:0x%02X", ctx.a, ctx.p, ((unsigned char*)mem6502)[0x20], ((unsigned char*)mem6502)[0x21], ((unsigned char*)mem6502)[0x22]);
    free(mem6502);
}

As far as I can tell the error appears to either be in the final stages of the run_6502 function (literally saving things into that ctx struct, nothing else) or in the OSReport call.

The bit where it gets weird is if that I comment out the if statement and its accompanying closing bracket the code runs flawlessly. I would like to leave them in because imho rendering every frame is a good idea but I don't necessarily want to spam up the console with all those OSReport calls.

I've tried disabling JIT and the error didn't change.

Any help would be appreciated. I have a sneaking suspicion that my code doesn't quite follow calling convention (who needs r13?) (Update: fixed calling convention, same crash) but that would simply cause an on-console exception right? Not this whole shemozzle. Thanks in advance.

[exjam]

Unfortunately I feel there isn't enough information here for me to diagnose exactly what the problem is. Would you be able to could upload the .rpx and I could help debug the issue myself?

p.s. r3-r12 are the volatile registers on PPC.

[ashquarky]

Sure thing. Don't remember what strange debugging step made it into this build so you'll have to excuse any odd code. Thanks!

RunApp is my main application, called from MainLoop (which also handles ProcUI stuff.) sub_2000294 is the Assembly stuff.

(also, the debugger doesn't seem to work on my machine, it just doesn't respond to input. Will open a new issue if this isn't a quick fix in the config like OSReport was)

[exjam]

In that .rpx looks like you do not save r0 in sub_2000294, you can see an "mflr r0", without a stw for r0 into the stack,, then "lwz r0, 8(r1)" and "blr", which leads to the application returning to an invalid memory location.

This assumes that sub_2000294 is your hand written assembly that is.

https://puu.sh/rN2pl/4c2223d23a.png

[exjam]

p.s. I normally see it like this:

stwu r1, -0x10(r1)
mflr r0
stw r0, 0x14(r1)

...

lwz r0, 0x14(r1)
mtlr r0
addi r1, r1, 0x10
blr

[ashquarky]

Thanks for that, swapping it to your stack system worked fine. I really thought it was a Decaf issue, really sorry that it turned out to me being silly :/

I suppose I should try and get the debugger working so I can do this myself in future, eh.