Exception handler delivery (sceKernelRaiseException, fault handlers)

[merwie]

Problem

sceKernelRaiseException(thread, signum) and delivery to handlers installed with sceKernelInstallExceptionHandler (recorded by #724) are not implemented.

Unity IL2CPP titles need them for garbage collection. PPSA12544's Media/Modules/PS5Util.prx installs a SIGUSR1 (30) handler and stops each thread with sceKernelRaiseException(thread, 30). The handler runs on the stopped thread, reads uc_mcontext.mc_rsp (offset 0xf8 of the context) and calls Unity's callback, which records the thread and waits through sceKernelSyncOnAddressWait until the collector wakes it. Details: #726.

Requirements taken from that code:

1. The handler runs on the target thread (the callback identifies the thread through its own thread state).
2. It receives (signum, ucontext*) with the PS5 layout: uc_sigmask (16 bytes), 48 bytes, then FreeBSD amd64 mcontext (mc_rdi ... mc_rsp, mc_rip, mc_rflags, mc_fsbase, ...).
3. When the handler returns, the thread resumes the interrupted code with the (possibly modified) context.
4. Targets are often blocked: in PPSA12544 the AssetGarbageCollectorHelper threads are inside host waits under libkernel when the first raise happens. The collector waits for every target's handler, so a target that never runs the handler deadlocks the title.

Host faults (SIGSEGV, SIGBUS, SIGILL, SIGFPE) to installed handlers are the same mechanism with a synchronous source.

Proposal

Linux. Map the guest signal to a host signal (a real-time signal for SIGUSR1, so it cannot collide with the host's own SIGUSR1 users), deliver it with pthread_kill to the target's native thread, and in a host SA_SIGINFO handler convert the host ucontext_t to the PS5 layout, call the guest handler, and copy the result back. Blocked syscalls are interrupted by the host signal; libkernel waits restart or return as their PS5 counterparts do.

Windows. There are no asynchronous signals, so two parts:

• Running code: SuspendThread + GetThreadContext, build the PS5 ucontext and a copy of the host CONTEXT on the target's stack below the red zone, point rip at a trampoline (rdi = signum, rsi = ucontext), SetThreadContext, ResumeThread. The trampoline calls the handler, writes the possibly modified registers back into the saved CONTEXT and returns with RtlRestoreContext.
• Blocked in a libkernel wait: a redirected context only takes effect when the wait returns. Make libkernel's guest waits (SyncOnAddress, condition variables, semaphores, event flags, nanosleep, equeue) wait on a per-thread alertable or signalable object as well; sceKernelRaiseException marks the signal pending and wakes the wait; the wait runs pending handlers on its own thread (with a context describing the return into the wait) and then resumes waiting with the remaining timeout.
• Raising on the calling thread runs the handler directly.

Faults go through a vectored exception handler that converts EXCEPTION_POINTERS the same way, when a guest handler is installed for the signal; otherwise the current crash report stays.

Questions

• Is extending the libkernel waits (the Windows blocked case) acceptable, or is there a preferred central wait path to hook?
• Which host signal number for guest SIGUSR1 on Linux, given the other host signal users in the project?
• Should the handler run with the guest signal blocked (FreeBSD default) and sigprocmask state (Signals.cpp) honoured from the start, or is that a follow-up?

I am willing to implement this in steps: Linux delivery and Windows running-thread delivery first (each with tests that raise on a busy thread and check the context), then the interruptible waits.

[treymouledoux]

This seems to be formatted as an issue. I would close this discussion and create an issue instead of explaining your problem.