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)
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
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
)