devkitPro / wut

Let's try to make a Wii U Toolchain / SDK for creating rpx/rpl.
zlib License
244 stars 52 forks source link

wutcrt: Fix the trap instruction and move it directly into __rpx_start #302

Closed Maschell closed 1 year ago

Maschell commented 1 year ago

Apparently the trap instruction (tw 0x1f, 30, 0 / 0x7ffe0008) is a "DBGCTL_INSTRUCTION" which excepts specific values in r3,r4 and r5. The gdb stub of the coreinit.rpl uses it to set an "initial breakpoint" which gets removed immediatly after it's hit once. Retail software loads "main" into r4 and "ctors" into r5. For now I decided to set r4 and r5 both to "main"

The code that is handling the exception does somelthing like this

[...]
auto trap_symbol = (DBGCTL_FLAGS) MasterAgent_GetRegister32(coreInfo, coreInfo->stoppedContext, 3);
auto r4          = MasterAgent_GetRegister32(coreInfo, coreInfo->stoppedContext, 4);
if(trap_symbol == DBGCTL_INIT_BREAKPOINT /* 2 */) {
    auto r5 = MasterAgent_GetRegister32(coreInfo, coreInfo->stoppedContext, 5);
    auto r5 = MasterAgent_GetRegister32(coreInfo, coreInfo->stoppedContext, 5);
    if (gInitialBreakpointSet == 0) {
        auto appFlags = __OSGetAppFlags();
        if (((appFlags & 0x40) != 0) || ((appFlags & 0x10) != 0)) {
            MasterAgent_SetInitialBreakpoint(r5);
        } else if ((appFlags & 0x20) == 0) {
            MasterAgent_SetInitialBreakpoint(r4);
        }
    }
    [...]
    return;
}

So depending on the "AppFlags" the breakpoint is set to either r4 or r5 (or not at all?).

I also moved it to the crt0_rpx.s instead of __init_wutto not have it in rpl (and anything else that uses __init_wut)

Maschell commented 1 year ago

Maybe instead setting the initial breakpoint tomain, we should set it to __init_wut? Otherwise we are not able to debug __init_wut at all