fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs+tools: scope the guest-PC experiment properly, and let ob_bitflag find the counter itself

Browse Source 
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
This commit is contained in:
Sylpheed RE agent
2026-08-24 00:41:47 +00:00
parent 6b3442ce8c
commit a27dddf93d
2 changed files with 65 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/re/mission-freeze-resume-spin.md
View File

@@ -213,3 +213,36 @@ before the region summary existed, so "these regions are busy while frozen" has
nothing to be compared against. The regions may simply be the busiest regions in
the game at all times. That comparison is one run away and is the obvious next
measurement.
---
## 2026-08-24 — scoping the "which guest PC is spinning" experiment
The next step this file named turns out to be **more expensive than it looked**,
and the reason is worth writing down before someone starts it:
* 🔴 **Xenia's stack walker is a stub on POSIX.** `stack_walker_posix.cc` is
twenty lines: `StackWalker::Create` logs *"Stack walker unimplemented on
posix"* and returns `nullptr`. So `ThreadDebugInfo::guest_pc` — the field the
debugger would fill — is never populated on this platform, and the clean
in-emulator route does not exist.
* 🔴 **`PPCContext` carries no live PC either.** The guest PC lives in host
registers between block boundaries; there is no field to read.
* 🟡 **A reverse host→guest map is buildable but is a real feature.** The code
cache already learns the mapping when it emits code
(`X64CodeCache::OnCodePlaced(guest_address, function_info, …)`); a sorted
host-range → guest-function index would make a host RIP interpretable. That is
~50 lines *plus* a way to sample another thread's RIP, which on POSIX means
piggybacking on the signal machinery xenia already uses to suspend threads.
**The cheap route that exists instead: `gdb`.** It is installed
(`/usr/bin/gdb`), and `ptrace_scope` is **1**, so a debugger may only attach to
its own descendants — which means `gdb -p <pid>` on a running emulator will be
refused, but launching the emulator **under** gdb works. `run-canary` execs
`$XENIA_BIN`, so pointing `XENIA_BIN` at a small wrapper that `exec`s
`gdb --args <real binary> "$@"` keeps the lockfile and the flags intact and makes
gdb the parent. A `thread apply all bt` on a frozen run would not name JIT
frames, but it would immediately separate *"spinning inside guest JIT code"* from
*"spinning in a xenia loop"* — which is the fork this investigation is stuck on.
Not attempted here; recorded so the next pass starts from the right end.