Possible Error/Bad-Instruction in Gecko Code Handler for C0 Code Usage

[Vega]

I'm currently working on a code, this code uses the typical ISFS Routine like my other codes...

Open -> Read - > Close -> Edit Heap -> Open -> Write - > Close

For initial beta testing, I was using the shared item address for the code, so the code was a C2 (InsertASM) Code at that time. Everything worked fine, I had no error values in function returns.

So I need the code ready at every frame, best way to do this is with the C0 Codetype. I get everything set up and the Code is a C0 Type. I get freezes no matter what. I found that during the first ISFS_Open, some crash would occur. I wouldn't even get a error return value, because the execution wouldn't even return from ISFS_Open. Just a plain crash.

The execution of the code would somehow return where my C0 Code is stored (at first instruction). Odd.

I decided to switch back to a C2 type (using some address that breaks every frame, I used this on other codes before), changed nothing of the source (other than add the default instruction of the new address), and BAM, it works.

So if anyone is interested, I will most likely release my new code tomorrow. You can convert it to a C0 type, add Star's Custom Exception Handler Code, and try to debug this. I have no desire to dig anymore into this.

[Vega]

Nevermind about tomorrow, code is released now - http://mkwii.com/showthread.php?tid=1218

[JoshuaMK]

Been making a hefty code that uses C0 and it is crashing like this as well. Who knew :/

[Vega]

Use the address of memset of memcpy, they are the same for every region. Before doing that though, try finding where the crash is at.

[JoshuaMK]

The crash is located a decent ways away from the code and changes every now and then. The code itself is almost done btw.

Maybe dumb, but where is this address?

[Vega]

https://mkwii.com/showthread.php?tid=922

Even though this is for PAL, the values for memcpy and memset are the same for every region. These addresses gets called all the time, so they execute every frame essentially.

[JoshuaMK]

So the crash is specifically from an invalid load from r13 + OFFSET into r31 in a function symbolized as "Exception Decreme....." I couldn't see the rest because I didn't have the time as I was just getting of the computer. Does this mean anything specific?

[Vega]

That's a Decrementer Exception (0x80000900). Either find the Broadway manual on the web somewhere (can't post it here), or find some generic PowerPC article about handling exceptions.

My uneducated half ass guess is that something with the code handler (via C0 usage) is messing up r13's value? And r13 should NEVER be modified.

[JoshuaMK]

The code is completely finished other than this one issue, so if I can fix it, I will be soooooooo happy

[Vega]

As mentioned earlier, you can easily use memcpy or memset address. Ye it would suck (code will be longer and not look clean), but it will work.

With either one you choose to use, r0, r3 thru r6 won't be safe. r7 might not be safe too. LR won't be safe either, and I can't remember about the CTR's safety. The CR might not be safe as well, use cr7 instead of cr0 if that's the case.

If you REALLY want to use the C0 codetype, then you gonna have to write in a hacky patch to (at the decrementer vector area) to attempt to fix the r13 issue. That would be a lot of investigating. Going that route, you might as well rewrite/fix the code handler on the C0 code types.