a27dddf93d
The freeze's named next step is more expensive than it looked, and the reasons are recorded before anyone starts it: xenia's stack walker is a TWENTY-LINE STUB on POSIX (Create logs "unimplemented" and returns nullptr), so ThreadDebugInfo::guest_pc is never filled here; PPCContext carries no live PC either. A reverse host->guest map is buildable - the code cache already learns the mapping in OnCodePlaced - but that plus a way to sample another thread's RIP is a real emulator feature, not a patch. The cheap route that does exist: gdb is installed and ptrace_scope is 1, so attaching to a running emulator is refused but launching it UNDER gdb is not - run-canary execs $XENIA_BIN, so a wrapper that execs "gdb --args <real binary>" keeps the lockfile and flags and makes gdb the parent. That would separate "spinning in guest JIT code" from "spinning in a xenia loop", which is the fork this is stuck on. Not attempted yet. ob_bitflag now locates the counter itself from the three addresses measured so far, instead of refusing when the default one is wrong. That costs no transitions, and with roughly half of all runs ending early, transitions are the scarce resource. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE