fabi/xenia-rs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: add migration/ bundle for cross-machine setup

Browse Source 
Bundles state that lives OUTSIDE the xenia-rs repo so a fresh clone on
another machine can be brought up to identical configuration via
migration/setup.sh:

  - claude-memory/             ~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/
                               (103 files, 1.1 MB - MEMORY.md + every
                                project_xenia_rs_*.md from audits
                                addis_signext through audit-058)
  - project-root/dot-claude/   <project-root>/.claude/settings.json
                               (Stop hook + permissions)
  - project-root/ppc-manual/   <project-root>/ppc-manual/
                               (PowerPC reference docs, 397 files, 3.7 MB)
  - project-root/run-canary.sh <project-root>/run-canary.sh
  - README.md                  Human-readable setup checklist
  - setup.sh                   Idempotent installer (also reclones
                               xenia-canary at pinned HEAD 6de80dffe)
  - MANIFEST.md                Per-file mapping + per-file-not-bundled
                               restoration recipe

Excluded from bundle (not shippable via git):
  - Sylpheed ISO (7.8 GB; copyright; manual copy required)
  - sylpheed.db (395 MB; regenerable from XEX via analysis tooling)
  - target/ build artifacts (rebuild on target)
  - audit-runs probe firehoses (.log/.stdout/.stderr ~11 GB; rerun if needed)
  - audit-runs memory dumps (.bin ~4.5 GB; rerun audit-026/027/029 if needed)
  - xenia-canary checkout (setup.sh reclones from
    git.mc02.dev/fabi/Xenia-Canary.git at HEAD 6de80dffe)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-05-10 21:38:38 +02:00
parent 8e709b0a24
commit e6d43a23ac
505 changed files with 86028 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
migration/MANIFEST.md Normal file
View File

@@ -0,0 +1,69 @@
# Migration MANIFEST
Generated 2026-05-10 from master `ac2f89a` for cross-machine carrier.
## Per-file mapping
| Source path in `migration/` | Bytes | Target path on new machine |
|---|---|---|
| `claude-memory/MEMORY.md` | * | `$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/MEMORY.md` |
| `claude-memory/project_*.md` (~102 files) | ~1.1 MB total | `$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/` |
| `project-root/dot-claude/settings.json` | small | `<project-root>/.claude/settings.json` |
| `project-root/ppc-manual/{alu,branch,categories,control,forms,fpu,generator,memory,vmx,vmx128}/` + `index.json` + `README.md` | ~3.7 MB | `<project-root>/ppc-manual/` |
| `project-root/run-canary.sh` | 199 B | `<project-root>/run-canary.sh` (chmod +x) |
| `README.md` | — | (this file, stays in repo) |
| `setup.sh` | — | (this file, stays in repo) |
| `MANIFEST.md` | — | (this file, stays in repo) |
Where `<project-root>` is the parent directory of the `xenia-rs` clone.
## Pinned references
- xenia-rs HEAD at snapshot time: **`ac2f89a`** (master, on this branch the tip is past it with 3 backfill commits)
- xenia-canary HEAD: **`6de80dffe261b368ecefee36c9b2b337335228c0`** — `setup.sh` checks this out automatically
- xenia-canary remote: `https://git.mc02.dev/fabi/Xenia-Canary.git`
- xenia-rs remote: `https://git.mc02.dev/fabi/xenia-rs.git`
## Last completed audit chain
```
AUDIT-050 (reframe) ───► AUDIT-051 (sub_8245B078 divergence)
│
▼
AUDIT-052 (struct dump → cache miss)
│
▼
AUDIT-053 (persistent cache test)
│
▼
LANDED 2a8ff95 ◄────────── AUDIT-054 (VFS layout fix + opt-in persist)
│
▼
AUDIT-055 (sub_8245B078 body parity)
│
▼
AUDIT-056 (LR distribution, 3.21× throughput gap)
│
▼
AUDIT-057 (13 missing threads, top sub_825070F0)
│
▼
AUDIT-058 (activation ladder, AUDIT-049 wedge upstream)
│
▼
[PAUSED] AUDIT-059 recommended (γ-wedge pivot on 0x12A4)
```
Each audit's findings are in `audit-runs/audit-NNN-.../` (committed) and
its memory file `project_xenia_rs_audit_NNN_*.md` (in `migration/claude-memory/`).
## Not in bundle (external)
| File | Why | How to restore |
|---|---|---|
| Sylpheed ISO (~7.8 GB) | Copyright + size | Manual copy from original machine |
| `sylpheed.db` (~395 MB) | Regenerable; permanent git bloat | Run analyzer after build |
| `target/` | Build artifacts | `cargo build --release` |
| `audit-runs/**/{*.log,*.stdout,*.stderr}` (~11 GB) | Probe firehoses | Rerun audit if needed |
| `audit-runs/**/*.bin` (~4.5 GB) | Memory dumps | Rerun audit-026/027/029 if needed |
| `xenia-canary/` checkout | Separate repo | `setup.sh` reclones automatically |

116
migration/README.md Normal file
View File

@@ -0,0 +1,116 @@
# Cross-machine migration snapshot
This directory bundles the parts of the working state that live OUTSIDE
the `xenia-rs` git repo, so a fresh clone on another machine can be brought
up to the exact same configuration without manual file-shuffling.
It is paired with branch **`chore/portable-snapshot`**. If you're reading
this on a machine other than the original, you are on that branch.
## TL;DR — how to set up a new machine
```bash
# 1. Clone into the canonical path (matches embedded paths in memory).
mkdir -p ~/'RE Project Sylpheed'
cd ~/'RE Project Sylpheed'
git clone https://git.mc02.dev/fabi/xenia-rs.git
cd xenia-rs
git checkout chore/portable-snapshot
# 2. Run the installer (idempotent; safe to re-run).
bash migration/setup.sh
# 3. Manual steps the script will remind you about:
# - Copy the Sylpheed ISO into the project root.
# - Regenerate sylpheed.db once (analysis tooling pulls XEX from the ISO).
# - Build canary Debug if you intend to run cross-runtime probes.
# - Switch back to master and continue from HEAD ac2f89a (or merge this
# branch into master if you want to keep the audit-runs/findings.md
# history; the branch is purely additive).
```
## What gets installed where
| Source under `migration/` | Target on new machine |
|---|---|
| `claude-memory/` (1.1 MB, 103 files) | `~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/` |
| `project-root/dot-claude/settings.json` | `<project-root>/.claude/settings.json` |
| `project-root/ppc-manual/` (3.7 MB) | `<project-root>/ppc-manual/` |
| `project-root/run-canary.sh` | `<project-root>/run-canary.sh` |
Where `<project-root>` is the parent directory of this xenia-rs clone
(i.e. `~/'RE Project Sylpheed'/` if you followed the TL;DR layout).
## What is NOT bundled and why
| Thing | Why excluded | How to restore on new machine |
|---|---|---|
| Sylpheed ISO (~7.8 GB) | Size + copyright; cannot ship via git | Copy manually from the original machine to `<project-root>/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso` |
| `sylpheed.db` (~395 MB) | Reproducible from XEX + analysis tooling; permanent git bloat | After cargo build, regenerate. See *Regenerating sylpheed.db* below |
| `xenia-canary` repo | Separate git project with own remote | `cd <project-root> && git clone https://git.mc02.dev/fabi/Xenia-Canary.git xenia-canary && cd xenia-canary && git checkout 6de80dffe`. (`setup.sh` does this automatically if the directory is missing.) |
| `target/` build artifacts | Reproducible via `cargo build` | `cargo build --release` |
| Probe `.log`/`.stdout`/`.stderr` raw dumps (~11 GB) | Already gitignored; only summaries committed | Not needed; rerun the relevant audit if you want fresh logs |
| Memory-dump `.bin` files (~4.5 GB) | Captured by audits 026/027/029; gitignored | Re-run those audits if needed |
## Regenerating sylpheed.db
After `cargo build --release` succeeds and the ISO is in place:
```bash
cd ~/'RE Project Sylpheed/xenia-rs'
# The analyzer binary scans the XEX inside the ISO and writes sylpheed.db
# next to it. (Exact subcommand to be confirmed against current main.rs:
# look near `--analyze` or `analyze` subcommand.)
cargo run --release --bin xenia-rs -- analyze \
"../Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso"
```
The output is `sylpheed.db` (~395 MB) and is gitignored.
If the analyzer subcommand has changed, the source of truth is the
post-M1-M12-overhaul analysis crates under
`crates/xenia-analysis/` + `crates/xenia-app/src/main.rs`. Check `--help`
for the current invocation.
## Picking up where the previous session left off
The most recent audit chain (050-058) is summarized in
`~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/MEMORY.md`
(restored by `setup.sh`). Specifically:
- Master HEAD `ac2f89a` — post-AUDIT-054 VFS layout fix.
- Plateau: `swaps=1 / draws=0`.
- Last unfinished audit: **AUDIT-059**. Recommended next step is in
`project_xenia_rs_audit_058_sub825070F0_activation_2026_05_10.md` —
pivot to unblocking the AUDIT-049 main-thread wedge (handle 0x12A4),
not chasing the static caller ladder of sub_825070F0 further.
To continue: instruct the agent on the new machine to "resume the
autonomous audit loop from AUDIT-059 per the memory file's
recommendations." The agent should read MEMORY.md first to load
context, then dispatch the next audit.
## Branch policy
`chore/portable-snapshot` is purely additive over master:
- Commit 1: `audit-findings.md` backfill (1943 lines of audit history)
- Commit 2: `audit-runs/` summary artifacts (~284 files, ~52 MB)
- Commit 3: this `migration/` directory + `.gitignore` `*.bin` exclusion
None of the commits touch crate source code. Merging into master is safe
once you're satisfied the new machine works. The branch can also be kept
as a stable snapshot anchor if you prefer keeping master purely "code".
## Verifying integrity post-setup
```bash
# After setup.sh:
ls "$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/" | wc -l # should be ~103
cat "$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/MEMORY.md" | head -5
cat "<project-root>/.claude/settings.json" | head -10
ls "<project-root>/ppc-manual/" # alu/ branch/ fpu/ etc.
ls "<project-root>/xenia-canary" # should exist after setup.sh
git -C "<project-root>/xenia-canary" rev-parse HEAD # 6de80dffe
```
If any of those checks fail, rerun `setup.sh` from inside `migration/`.

105
migration/claude-memory/MEMORY.md Normal file
View File

@@ -0,0 +1,105 @@
# Memory Index
- [audit_058_sub825070F0_activation](project_xenia_rs_audit_058_sub825070F0_activation_2026_05_10.md) — Canary fires sub_825070F0 1× after `DiscImageDevice::ResolvePath(\\dat\\movie)`. Static caller ladder (6 levels: sub_824F7800 ← sub_824F7CD0 ← sub_824F8398 ← sub_821B55D8 ← sub_821B6DF4 [top]). ALL 6 fire 0× in ours. Break is NOT CRT-fnptr-array — it's the AUDIT-049 main-thread wedge (handle 0x12A4 wait at 0x824ac578) blocking the entire post-intro phase. Vtables 0x8200A208/0x8200A928 have **zero vptr_writes in DB** — writer ctor is computed-store-only OR in unreachability island. Confirms AUDIT-050 half-bootstrap: vtable-writer subset dead. AUDIT-059: pivot to unblocking the wedge (049+057 unified γ-investigation), not chasing caller-ladder further.
- [audit_057_thread_gap](project_xenia_rs_audit_057_thread_gap_2026_05_10.md) — Canary 23 thread-spawns / ours 10 = **13 missing**. 8 distinct missing-thread spawners. **Top: sub_825070F0** (4 missing, initializes 4 workers w/ shared ctx 0xBCE25340, entries 0x82506528/58/88/B8). **11 of 13** from spawners that don't fire at all in ours — same audit-050 CRT-fnptr-array unreachability. sub_821C4EB0 fires (1×) but early-returns (audit-056); sub_821746B0 fires 1× / should spawn 2. AUDIT-058: probe sub_825070F0 activation chain in canary, find fnptr-array entry ours doesn't enumerate. Cascade D 10-20% (multiple independent gaps).
- [audit_056_producer_trace](project_xenia_rs_audit_056_producer_trace_2026_05_10.md) — LR distribution at sub_82452DC0: canary 45/60s vs ours 14/26s (3.21× ratio). **Two CANARY-ONLY divergence introducers**: (a) sub_821C4EB0 calls sub_821CEDF8 5× in canary, 0× in ours despite IDENTICAL caller-LR — early-exit somewhere in +0x44..+0xE0; (b) sub_824AFF88 thread-trampoline fires 5× canary / 0× ours — **12 vs 30 XThread count gap** (18 missing threads). 3.0× thread-count ratio matches 3.21× throughput ratio. AUDIT-057: probe sub_82174828 + post-bl PCs inside sub_821C4EB0 (`0x821C4F2C/0x821C5014/0x821C5048`); fallback = audit which 18 thread-creates fail to land. Wine canary not yet justified.
- [audit_055_subB078_internal](project_xenia_rs_audit_055_subB078_internal_2026_05_10.md) — Probed sub_8245B078's body with cache override: BODY EXECUTES CORRECTLY (internal call parity ~98%, sub_8217FA08 2449/2411). Divergence is UPSTREAM — sub_82452DC0 fires 5.6× less in ours. Sharpest specific divergence: sub_8217FA08 from LR=0x82455E60 (=sub_82455DF0+0x70), canary 20 / ours 0. Bug class refined: **δ-throughput** (producer of work items doesn't fire at canary rate). AUDIT-056 recommendation: probe sub_82452DC0 entry, aggregate LR distribution upward.
- [audit_054_vfs_layout_landed](project_xenia_rs_audit_054_vfs_layout_landed_2026_05_10.md) — **TRACK A LANDED**: commits `2a8ff95` (74 LOC) + `ac2f89a` (golden re-baseline). FILE_DIRECTORY_FILE bit threaded through nt_create_file → open_cache_file. `cache:\<HASH>` with disp=2 opts=0x4021 → mkdir; leaf paths with opts=0x4020 → file. Closes ζ-class layout aliasing. Track B persistent cache OPT-IN via `XENIA_CACHE_PERSIST=1`; default keeps AUDIT-038 wipe for lockstep. Cascade A/B confirmed via AUDIT-053 Phase 1 (canary cache override); **cascade C/D STILL FAIL** — cache is necessary but not sufficient. Warm-start regression (cxx_throw=10) when persistent enabled — our cold-start halts at swaps=1 producing half-baked .tmp journals. Next: probe sub_8245B078 internal body to find next gate.
- [audit_053_cache_layout_bug](project_xenia_rs_audit_053_cache_layout_bug_2026_05_10.md) — Phase 1 confirms AUDIT-052 gate hypothesis (PCs `0x82452E30`/`0x8245B078`/`0x8245AD94` go 0→6 with canary cache override; cascade A/B PASS) BUT cascade C/D FAIL (NtSetEvent 68→63, VdSwap=1 unchanged). Phase 2 permanent fix REVERTED — warm-start regression from VFS layout aliasing: `open_cache_file` treats all `NtCreateFile` as files, but `cache:\d4ea4615 disp=CREATE` is meant as a DIRECTORY. 0-byte file blocks hierarchical creates. AUDIT-038 wipe masked this for 14 audits. **15th reading-error class ζ**: VFS layout aliasing. AUDIT-054 = honor `FILE_DIRECTORY_FILE` bit + retry persistent cache.
- [audit_052_cache_root_cause](project_xenia_rs_audit_052_cache_root_cause_2026_05_10.md) — **🔥 ROOT CAUSE FOUND**: AUDIT-051 struct hypothesis REFUTED (struct bit-identical canary/ours). `[r3+0]`/`[r3+4]` are halves of a hash key formatted into `cache:\<HASH1>\<X>\<HASH2>` paths. Real bug: `NtQueryFullAttributesFile` returns -1 for `cache:\*` in ours because **AUDIT-038's per-boot tmpdir cache is WIPED every startup**. Canary's `~/.local/share/Xenia/cache/` is persistent + pre-populated (d4ea4615/e/46ee8ca etc — game-built shader/PSO/material caches). **Reading-error class #15**: AUDIT-038 "missing-or-stale ≡ fresh" assumption invalidated. Fix = persistent cache (`crates/xenia-kernel/src/state.rs:387-398`). Cascade A/B/C HIGH; D 30-40% (cache may not be only gate).
- [audit_051_work_submitter_trace](project_xenia_rs_audit_051_work_submitter_trace_2026_05_10.md) — **CONCRETE DIVERGENCE FOUND**: `sub_8245B078` fires 18× canary / 0× ours. Gate at `sub_82452DC0+0x78` (PC `0x82452E2C beq cr6, 0x82452E88`) controlled by `sub_8245B000` returning 1 iff `[r3+0]≠0 AND [r3+4]≠0` for 80-byte stack-local struct at `r31+96`. Ours has one of those fields NULL — missing-population. Struct upstream-written by `sub_8245AE50`/`sub_82452068`/`sub_82452200` (fire in both, ours doesn't write right fields). **Single root cause** for AUDIT-047's 4 wedges (0x10A0/0x10A4/0x1530/0x1534) via `sub_8245AD00` + plausibly tid=13's stall on 0x1288. Direct-bl divergence (NOT vtable) — at this level. AUDIT-052: dump struct at PC `0x82452E1C` in both engines, find NULL field, identify missing writer. Cascade D 20-30% (5 vtable dispatches downstream might re-hit island).
- [audit_050_reframe](project_xenia_rs_audit_050_reframe_2026_05_10.md) — **🔥 METHODOLOGICAL REFRAME (2026-05-10)**: 11 prior audits' "audit-009 cluster unreachable" claim is STATIC-ANALYZER ARTIFACT. `--ctor-probe` shows CRT driver `sub_824ACB38` (called from entry_point) iterates 0x82870xxx fnptr arrays (557 slots, 82 non-NULL); `sub_8280E148` (RegisterToFactory<silph::GamePart_Title>) fires at cycle 1.4M; tid=13 chain (sub_821C4EB0/sub_821CC3F8/sub_821CBA08/sub_821CB030) fires; **work-submitter sub_82452DC0 fires on tid=13 at cycle 8127**. Real bug = γ missing-signaler inside sub_82452DC0's descendant tree. **14th reading-error class**: BFS-only insufficient when binary uses CRT-driven fnptr arrays. **Angle B (-n 5B) DEFINITIVELY FALSIFIED** (bit-identical to 500M). Cluster is HALF-bootstrapped (worker-thread subset live, vtable-writer subset dead) — virtual dispatches hit garbage. Wine canary no longer only route. Top angle: probe sub_82452DC0's 9 direct targets + 1 ind_call (`0x8245AE50,0x82452068,0x82452200,0x8245B000,0x8245B078,0x82454A40,0x82452AB8,0x82454918,0x82452EC4`) in both engines, find divergent branch. Cascade D=draws>0 YES POSSIBLE 30-50%.
- [audit_049_tid1_stall_0x1280](project_xenia_rs_audit_049_tid1_stall_2026_05_10.md) — Post-AUDIT-032 wedge: handle 0x1280 = **Thread handle** for tid=13 (not event); tid=1 is doing thread-join. Real sub-stall: tid=13 waits INFINITE on event 0x1288 (created at `sub_821CB030+0x128`, in audit-009 cluster front-end UI). 5 NtSetEvent callers in worker cluster `0x82450000-0x8245C000`: only `sub_82452DC0` (work-submitter) statically reachable; rest unreachable. tid=13 create-chain: `sub_821748F0`→`sub_821C4EB0(UImpl@GamePart_Title@silph)`→`sub_821CC3F8(AVGamePart_Title)`→`sub_821CBA08`→`sub_821CB030`. All in audit-009 island. Discipline 3/5 PASS, D=draws>0 NO. **5th consecutive audit (044/045/046/047/049) converging on same unreachability island.** Path 1 (Wine canary) now justified per user's "meaningful progress" framing.
- [audit_048_audio_host_pump_fix](project_xenia_rs_audit_048_audio_host_pump_fix_2026_05_10.md) — **PATH 2 LANDED in working tree (not committed)**. AUDIT-032 audio fix: dedicated audio worker thread per client, 75 net LOC across 4 files. Cascade A/B/D ✅ — tid=9/10 unblock from `0x828a3254`/`0x828a3230`, KeReleaseSemaphore 0→1, xaudio.callback.delivered=1. swaps 2→1 (degenerate splash lost). draws 0→0 (expected — audio≠renderer per AUDIT-032). **Boot phase advanced**: NtWaitForSingleObjectEx 1.4M→30, NEW StfsCreateDevice/XamContent*/ExCreateThread×10/XeCryptSha/etc. New stall: tid=1 main Blocked on handle 0x1280 at pc=0x824ac578. Tests pass (kernel 127/127, app 5/5 non-ignored). Lockstep goldens deferred (will drift).
- [autonomous_run_synthesis](project_xenia_rs_autonomous_run_synthesis_2026_05_10.md) — **AUTONOMOUS-MODE SYNTHESIS (2026-05-10, sessions 5-8 of 10 used; 9-10 RESERVED)**: 4 audits (044-047) refuted 4 hypotheses; no fix landed; no draws cascade; methodological floor reached within Linux Debug + READ-ONLY discipline. Cluster activation past Linux Debug horizon. Best near-reachable signaler `sub_8245AD00` covers 4 wedges but its callers sit in audit-009 unreachability island. KeReleaseSemaphore 0 ours / 73,914 canary = AUDIT-032 audio host-pump gap (already named). Three paths forward (user pick): (1) Wine/Lutris canary build for new oracle [HIGH effort/reward], (2) audit-032 audio host-pump fix [MEDIUM effort, D≠draws], (3) guest-thread injection [HIGH risk]. Sessions 9-10 held in reserve.
- [audit_047_gamma_wedges](project_xenia_rs_audit_047_gamma_wedges_2026_05_10.md) — 10 NO_SIGNALS handles inventoried + XAudio. `sub_8245AD00` reachable, covers 4 wedges (0x10A0/0x10A4/0x1530/0x1534), but callers in audit-009 island. Of 125 signal-source fns, only 2 statically-reachable + near-wedge: sub_8245AD00, sub_82450218. KeReleaseSemaphore 0/73914 canary divergence = known AUDIT-032 audio host-pump (PC 0x824D229C, r3=0x828A3230). Discipline 3/5 PASS, D=draws>0 NO. γ-wedge convergence: all hit audit-009 unreachability island.
- [audit_046_loop_exit](project_xenia_rs_audit_046_loop_exit_2026_05_10.md) — REFUTES audit-035 slot-pointer-region divergence as causal AND audit-034 "canary 3.75/5 vs ours 5/5" iter divergence. Both engines run 5/5 iters at sub_82450720+0x160..+0x1F4, fall through to no-match exit. Slot-table region split (canary 0xBC3xxxxx vs ours 0x4024xxxx) is REAL but BEHAVIORALLY INERT — predicate compares within each engine's own heap region. **Drop sub_82450720 chain as critical-path target.** Reading-error #13 (mid-block PC unprobeable in ours) reconfirmed; workaround via post-bne block-entry PC `0x82450908`. Recommended AUDIT-047: γ-cluster handle wedges per audit-042 (handles `0x10A0+0x10A4`, `0x12AC`, `0x1004`, etc).
- [audit_045_cluster_ctor_probe](project_xenia_rs_audit_045_cluster_ctor_probe_2026_05_10.md) — REFUTES audit-044 ctor hypothesis: `0x8228FAC8` (vptr write) + `0x8228F858` (ctor entry) fire **0× in CANARY too** at 50s. Cluster genuinely not activated at this horizon either engine — RECONCILE-B (Linux Vulkan/XCB) blocks before front-end-UI activation. T6 (audit-033 LR `0x82172BF8`) fires in both — gateway chain `entry→sub_8216EA68→sub_822F1AA8→sub_82172BA0` runs; cluster-ctor branch off it doesn't. **13th reading-error class**: probe-firing-granularity — ours `--pc-probe` fires only at basic-block entry, canary `--log_lr_on_pc` per-instruction; mid-block PCs systematically give ours=0. Recommended AUDIT-046: probe loop-exit predicate `0x82450904` (audit-034 5/5 vs 3.75/5 divergence). DB caveat: `v_call_graph` uses `xrefs.source`; prefer `xrefs.source_func` for caller-set queries.
- [audit_044_m55_cluster_survey](project_xenia_rs_audit_044_m55_cluster_survey_2026_05_09.md) — M5.5 lifts cluster `0x82285000-0x82294000` from 0/321 static-reach to 41/321 indirect (12.8%); only 4 vtable methods are entries. Cluster's 6 vptr-writer constructors all dead. Top probe: `sub_8228F858` writer at `0x8228FAC8` (vtable `0x820a9c28` ctor). Audit-033 chain ends genuinely at `sub_821CECF0`/`sub_821C4988` (7-hop BFS finds no ancestor). M5.5 `cand_count≤10` actionable; `=203` noise.
- [project_xenia_rs_audit_043_record_zero_offset_2026_05_09.md](project_xenia_rs_audit_043_record_zero_offset_2026_05_09.md) — **🎯 KRNBUG-AUDIT-043 (2026-05-09, READ-ONLY, master `d8766c6` tests 645)**: identifies writer of +0x00 at "records" 0x40542300/40/400/4C0. Mem-watch (-n 500M) → writer = memcpy `pc=0x825F1080 lr=0x825ED608` called from `std::basic_string::reserve_then_assign sub_8216E138+0xC8`. **Records are not records** — they are 64-byte slots in Sylpheed's pool allocator (`sub_821505D8` allocs 58MB via `sub_824A8858`; `sub_82152728` chains 64-byte free-list over 1.25MB; bucket sizes 4/16/32/64/96/128/160/192/256). Audit-030 patch reapplied; canary probe at `pc=0x825F1080`: 94,945 fires/25s, **zero hit `0x40542xxx`**, top destinations `0x705Dxxxx`/`0xBC36xxxx` (canary's pool base = `0xBC32C880` per pool-init probe). **Audit-039's "0xF80000B8 vs game" comparison is a VA-equality fallacy**: same guest VA backs different live data because allocator returns different host VAs in canary vs ours. Bug class **ε (host-allocator address-space divergence)** — NOT a guest-write bug, NO missing/wrong write at +0x00 in our impl. **Reading-error ledger 12th entry**: VA-equality fallacy across emulators — comparing memory at identical guest VAs assumes both allocators return same VA for same logical alloc; Sylpheed's pool factory makes this assumption false in general. **Recommended audit-044**: drop "record at 0x40542300+" line entirely; pivot to audit-042's actually-stalled-handle plan (0x10A0+0x10A4 worker pair, 0x12AC sema, 0x1004 event/manual). Bug class for next = γ (missing signaler). Trace `audit-runs/audit-043-record-zero-offset/{mem-watch.log, mem-watch.stdout, canary-825f1080-traces.txt.gz, audit-043-canary-poolinit.log}`. Discipline 5/5 PASS; canary patch reverted clean; xenia-rs source unmodified.
- [project_xenia_rs_audit_042_handle_lifecycle_2026_05_09.md](project_xenia_rs_audit_042_handle_lifecycle_2026_05_09.md) — **🎯 KRNBUG-AUDIT-042 (2026-05-09, READ-ONLY, master `d8766c6` tests 645)**: disambiguates audit-041 root cause for handle 0x1454 missed wakeup. Re-applied audit-030 canary patch (30 LOC, reverted clean canary `6de80dffe`). Method: ours `--trace-handles-focus=0x1454` (existing audit.rs); canary `--log_lr_on_pc=0x8284DF1C` (NtCreateEvent ord 209) + cross-ref audit-041 log. **STRUCTURAL FINDING**: `KernelState::alloc_handle` (state.rs:588) is **monotonic atomic counter** `fetch_add(4)` from 0x1000 — **bump-only, NO recycling, structurally impossible**. `nt_close` removes object but never returns ID to pool. **Lifecycle of 0x1454 in ours** (2 reruns identical): created tid=13 lr=0x824a9f6c (NtCreateEvent, kind=Event/Manual), waited tid=13 lr=0x824ac578 (do_wait_single), signaled tid=5 lr=0x824aa304 (NtSetEvent), wake fired (wake_eligible_waiters/auto). Final: waiters=0 signaled=true wakes=1 — **fully consumed, NOT stuck**. Created stack frames sub_822DFC74←sub_822E0344←sub_822D2CA4←sub_822DE768←sub_821C4B1C. **Lifecycle of canary F80000CC family**: 5+ Added/Removed/Added cycles in 30s (XObject→XEvent→XEvent→...). **Slab/free-list allocator**: F8000098 reused 130×, F80000D0 95×, F80000DC 71× per 30s window. **VERDICT: ROOT CAUSE NOT (A) HANDLE-RECYCLING** — recycling structurally impossible in ours; signal lands on same KEVENT object the wait registered for. **Audit-041's premise provisionally falsified for 0x1454**: audit-041 inferred stall from `--lr-trace` "7 pre-bl, 6 post-bl" but ran `--quiet` so end-of-run dump was suppressed; post-bl miss explained by KeWaitForSingleObject's wake-side context-restore bypassing post-bl PC. **Real wedges** (this run's stalled handles): `0x1004` (tid=11), `0x1020` (tid=3), `0x1040` (tid=5), `0x1544` (tid=17), `0x1578` (tid=19), `0x12ac` (tid=14,15), `0x10a0+0x10a4` (tid=6) — all `<NO_SIGNALS_DESPITE_WAITS>`. **Bug class**: δ-namespace + δ-wakeup BOTH RULED OUT for 0x1454; wedge migrates to **γ (missing-signaler)** on different handle set. Sharp 4-dim cascade prediction (audit-043 fix on real handle): A=signal_attempts 0→≥1, B=stalled tid Blocked→Ready, C=`<NO_SIGNALS>` count drops ≥2, D=swaps>2 OR draws>0 (low probability — γ-cluster plateau). **Recommended audit-043**: pivot to (1) `0x10a0+0x10a4` Event+Sema worker pair on tid=6, (2) `0x12ac` Sema with 2 waiters, (3) `0x1004` Event/Manual on tid=11. Trace `audit-runs/audit-042-handle-lifecycle/{probe.log, probe-run2.log, canary-create-0x8284DF1C.log}` (~11.5 MB). Discipline gate 5/5 PASS. xenia-rs source unmodified, no commit.
- [project_xenia_rs_audit_041_wait_site_2026_05_09.md](project_xenia_rs_audit_041_wait_site_2026_05_09.md) — **🎯 KRNBUG-AUDIT-041 (2026-05-09, READ-ONLY, master `d8766c6` tests 645)**: wait-site signaler determination. Re-applied audit-030 patch (30 LOC, reverted clean canary `6de80dffe`). Wait at PC `0x822DFC34 bl 0x824AA330` (KeWaitForSingleObject INFINITE) inside sub_822DFBC8 — direct caller of audit-040's NtCreateEvent. **Wait completion (canary 30s vs ours 500M-instr)**: canary 9 bl + 9 post-bl = **100%**; ours 7 pre-bl (probe at `bl` elided in HIR; pre-bl `0x822DFC30 addi r4,r0,-1` is fair) + 6 post-bl = **6/7 = 85%**. **7th wait stalls on handle `0x00001454`** (audit-040 family) at cycle 48,849. **Outcome (i) confirmed**: handle-namespace divergence is **load-bearing**. **Signaler = NtSetEvent** (xboxkrnl ord 246, thunk 0x8284DF5C): canary 9245 fires, **2 on F80000CC/C0** with LR=0x824AA304 (wrapper sub_824AA2F0, 89 callers). KeSetEvent 20588 fires, 0 on those handles (takes KEVENT*). **Cross-check**: ours's NtSetEvent fires **1× on r3=0x1454** at cycle 3,519,453 (AFTER stall) — **signaler IS firing in ours, but waiter not woken**. Bug class refined to **δ-namespace + δ-wakeup composite**: signal-before-wait race ruled out (signal is later); candidate causes = (a) handle slot 0x1454 recycled between create-epochs so signal hits different KEVENT than wait registered for, OR (b) KeSetEvent/wait-queue plumbing has missed-wake. **Recommended audit-042** (two-track): (1) probe sub_824AA2F0 entry filtering r3=0x1454 to name signaler caller chain; (2) dump our handle table state for slot 0x1454 at cycle 48,849 (wait) vs 3,519,453 (signal) — if different KEVENT pointers → handle aliasing in `xenia_kernel::handle_table`; if same → wait-queue bug. Both fixes ≤60 LOC. xenia-rs HEAD `d8766c6` unchanged. Trace `audit-runs/audit-041-wait-site/`.
- [project_xenia_rs_audit_040_record_ctor_inputs_2026_05_09.md](project_xenia_rs_audit_040_record_ctor_inputs_2026_05_09.md) — **🎯 KRNBUG-AUDIT-040 (2026-05-09, READ-ONLY, master `d8766c6` tests 645)**: identified divergent INPUT to sub_8244FC90 record ctor. Re-applied audit-030 patch + extended TrapLogLR (+56 LOC, reverted clean). Canary 33 fires at 30s; ours 8 fires via `--lr-trace`. Calling conv: r3=dest, **r4=28-byte source struct ptr (memcpy'd to dest+0x3C)**, r5=2nd this, r6/r7=scalars. LR=`0x82450440` (=sub_824503A0+0xA0) IDENTICAL in both. **Divergent dword**: `*r4+0` = canary `0xF80000DC` vs ours `0x00001454` — **NtCreateEvent OUT handle** (xboxkrnl ord 209 thunk `0x8284DF1C`). Upstream chain: sub_8244FC90 ← sub_824503A0 ← sub_824528A8 ← sub_822DFBC8 ← **sub_822DFC74** (which calls sub_824A9F18→NtCreateEvent at +0xC8C, stores result at `[r31+44]` then dispatches via vtable[7]). Both runtimes call NtCreateEvent 395× successfully — divergence is **handle-namespace cosmetics** (canary `0xF8000xxx` XObject-kernel-region vs ours `0x10xx-0x14xx` KernelState-handle-table-id). **Bug class δ-namespace** (handle representation; benign unless downstream interprets bits semantically). **AUDIT-037 framing partial-correction**: the inline filename text lives at dest record's `+0x40+` (written by sibling callees `sub_822F8A70`/`sub_82150030` AFTER sub_8244FC90 returns), NOT in the 28-byte memcpy region. **Recommended audit-041**: probe `sub_822DFC34` (`bl 0x824AA330` waitsite) in BOTH runtimes — if canary's wait completes but ours doesn't = signaler-missing bug. If both stall = handle namespace finding is benign and pivot to RDX search-criteria producer. Trace `audit-runs/audit-040-record-ctor-inputs/{canary-0x8244FC90.log, ours-lrtrace.jsonl, ours-dump.log, canary-patch.diff}`. xenia-canary HEAD `6de80dffe` clean; xenia-rs HEAD `d8766c6` unchanged.
- [project_xenia_rs_audit_039_track_2_extended_canary_2026_05_09.md](project_xenia_rs_audit_039_track_2_extended_canary_2026_05_09.md) — **🎯 AUDIT-039 TRACK 2 (2026-05-09, READ-ONLY, canary `6de80dffe`, xenia-rs `d8766c6`)**: extended-horizon canary trace for cluster activation. Re-applied audit-030 `--log_lr_on_pc` patch (30 LOC, 4 files); reverted clean. Probed 3 Tier-2 PCs serially (audit-031 single-PC constraint), 15-min wallclock each: **0x82172524 = 0 fires / 22 min**, **0x82175810 = 0 fires / 15 min**, **0x8217EB78 = 0 fires / 15 min**. ~52 min canary CPU total. Steady-state mix 240k KeReleaseSemaphore + 75k VdRetrainEDRAM/XamInputGetCapabilities loop in all 3. Per task brief Step 3 outcome **(ii)**: cluster activation past Linux Debug's reach in 15 min — skipped Tier-1 (3 PCs) + L1 (6 PCs) per compressed plan (consequences of Tier-2). Confirms+extends audit-034 Phase B (5 min, 0×) and VERIFY-A (35 sec, 0/12). RECONCILE-B host-presenter caveat dominates: Vulkan/XCB Linux fails to display intro video, front-end-UI state machine never advances past post-intro. **3 horizons (35 sec/5 min/15 min) all stop in same idle loop.** Sister Track 1's cascade-A verdict FAIL combined with this OUTCOME (ii): transformation-step (`RtlInitAnsiString`-driven filename externalization) IS missing AND cluster activation IS past Linux Debug reach — independent gates. **Recommended pivot B (static-only, M5.5 alias-aware vtable dispatch resolution)** first; pivot A (Lutris Windows canary instrumentation) as fallback. Trace `audit-runs/audit-039-track-2-extended-canary/canary-0x{82172524,82175810,8217EB78}.{log,err}`. Canary patch reverted, HEAD `6de80dffe` unchanged; xenia-rs HEAD `d8766c6` untouched, tests 645.
- [project_xenia_rs_audit_039_track_1_verify_2026_05_09.md](project_xenia_rs_audit_039_track_1_verify_2026_05_09.md) — **🎯 AUDIT-039 TRACK 1 (2026-05-09, READ-ONLY, master `d8766c6`)**: cascade dimension A verification post audit-038 cache fix. Probe sub_8228E498 = 0 fires (silenced by fix). Fallback `--dump-addr` 0x40542300/40/400/4C0 + extended 0x40542100..800. **VERDICT: FAIL** — 0x40542300 IDENTICAL to audit-037 pre-fix (inline "game:\\hidden\\Resource3D\\Common.xpr…", +0x20=0x7072005C "pr\\0\\\\" text bytes); 0x405424c0 has descriptor-shape pointers at +0x20=0x40541ED8 but **filename still inlined at +0x44** ("ptc_pack.xpr"). Canary records hold pointers (0xF80000B8 handle@+0, BC65xxx/BC36xxx sub-pointers); strings live on separate `RtlInitAnsiString`-allocated heap. Cache fix is correct hygiene (silenced sub_82459D18/sub_8245D230/0x82450904) but DID NOT externalize filenames into ANSI-string heap. **Bug class η record-layout divergence (audit-036) PERSISTS** — record-population transformation step is upstream/sibling of cache machinery, untouched by audit-038. Lockstep instr=500000019 stable, swaps=2. **Recommended next**: (A) trace `RtlInitAnsiString` callers vs canary to find missing `game:/dat:/cache:` prefix populator, (B) mem-watch +0x20 of 0x40542320 to capture writer PC+LR, (C) wait for sister Track 2's extended-horizon canary trace before declaring transformation-step missing, (D) KRNBUG entry on `RtlInitAnsiString` prefix branching. Trace `audit-runs/audit-039-track-1-verify/{probe-element,dump-extended}.{out,log}`. xenia-rs HEAD `d8766c6` unchanged.
- [project_xenia_rs_audit_036_vptr_deref_2026_05_09.md](project_xenia_rs_audit_036_vptr_deref_2026_05_09.md) — **🎯 KRNBUG-AUDIT-036 (2026-05-09, READ-ONLY, master `9028021`)**: hypothesis test of audit-035 narrative — captured `[[r3+0]+32]` at sub_8228E498/sub_82451E20+0x58 in BOTH runtimes. Canary patch 49 LOC (audit-030 base + 19-LOC TrapLogLR ext to deref `[r3+0]` + 64-byte struct dump); reverted clean. **Disasm correction**: sub_8228E498 is a deque iterator deref returning element_address (NOT vtable dispatcher); the `[+32]` deref happens in CALLER sub_82451E20 at PC 0x82451E78 reading the returned element's `[+0]` (key) then `[key+32]`. **Canary value `[[r3+0]+32]` = `0xBC65D018/D2D8/CFD8/D118/D198/D398`** — phys-heap pointers. **Ours value `[[r3+0]+32]` = `0x7072005C`** — mid-FILENAME-STRING text bytes ("pr\\0\\\\" from "...Common.xpr\\0\\..."). **VERDICT: REFUTED-AS-STATED** — ours's value is text not a heap pointer. **STRONGER finding**: records held by container have FUNDAMENTALLY DIFFERENT LAYOUTS. Canary's `[r3+0]=0xBC65D1C0` is a 16-dword pointer-bearing struct (handle@+0=0xF80000B8, sub-pointers@+32/+36/+44). Ours's `[r3+0]=0x40542300` is a struct STARTING WITH inline filename "game:\\hidden\\Resource3D\\Common.xpr\\0..." — offset 32 falls inside string text. Predicate `r28 == [[r3+0]+32]` compares stack pointers vs string bytes in ours (impossible match). Bug class **η — record-layout divergence (NEW class)**, distinct from audit-035's heap-region axis. **Recommendation: DO NOT proceed with physical-heap separation as audit-037** — even after heap-split, ours's records would still hold inline strings; predicate would still fail. **Audit-037 = identify the record populator** that builds container elements (mem-watch on `0x40542300+0x20` → writer PC + LR, walk caller chain, compare to canary's resource-loader). xenia-rs HEAD `9028021` unchanged. Tests 640. Trace `audit-runs/audit-036-vptr-deref/{canary.log, canary-callsite.log, ours.log, ours-exit.log, ours-final.log}`.
- [project_xenia_rs_audit_035_slot_table_2026_05_08.md](project_xenia_rs_audit_035_slot_table_2026_05_08.md) — **🎯 KRNBUG-AUDIT-035 (2026-05-09, READ-ONLY, master `9028021`)**: re-applied audit-030 patch + extended TrapLogLR (+19 LOC, total 49) to dump 5×20-byte slot table from r3+108 at sub_82450720 entry. Disasm verified r26+108 / 5 slots / 20 stride. r3=r26=0x828F3B68, base=0x828F3BD4 in BOTH runtimes. Canary 22 entries / 30s wall; ours --dump-addr at 50M (==500M, identical). **Diff**: slots 1/2/4 same shape (zeros + ptr + size 8) but ptrs in **canary 0xBC3xxxxx (physical heap)** vs **ours 0x4024xxxx (v40 bump heap)**; slot 3 canary `(2,5)` push counters vs ours `(0,0)` (ours over-cycles 0..0xB). Slot 0 zero in both. **Bug class ε — heap-region cross-reference mismatch**: predicate at 0x82450904 compares sub_82451E20's vptr-table-derived sum vs slot's local sum; the table walked via sub_8228E498's `[r3+0][32]` holds canary-physical addresses, but slot writers push v40 addresses on ours — per-element inconsistency causes predicate to never match early in ours. 1066 mem-watch hits on slot 3 ours (writers at sub_82450bc4 chain + 0x822f8b20/0x82323364/0x8231eee8). **Falsifies audit-034**'s "different positions" — slots match in shape, mismatch is in pointer value. **Sharp cascade**: A=land physical-heap separation (CPPBUG-AUDIT-001); B=sub_8228E498 vtable + slot writers same heap region; C=predicate matches iter 1-2; D=`draws>0` UNKNOWN. Pointed-to objects: 0x4024A240=vtable-headed (vptr=0x40111860), valid. Connects directly to audit-027/029. Canary patch reverted; xenia-rs HEAD `9028021` unchanged. Tests 640. Trace `audit-runs/audit-035-slot-table/{canary-0x82450720-fix.log, ours-lrtrace.jsonl, ours-dump-stdout.log, ours-memwatch-slot3.log}`.
- [project_xenia_rs_audit_034_frame_chain_divergence_2026_05_08.md](project_xenia_rs_audit_034_frame_chain_divergence_2026_05_08.md) — **🎯 KRNBUG-AUDIT-034 (2026-05-09, READ-ONLY, master `9028021`)**: re-applied audit-030 patch; probed audit-033's full 8-PC ours-side chain in canary 50s + ours -n 500M. **Firing matrix** L0..L5 uniform **6.3× divergence** (sub_821C4988=1/1, sub_821CECF0=2/2, sub_821CBEA8=7/7, sub_821CD458=7/7, sub_821CB968=14/14, sub_82450638=14/14 — same shape, ours iterates 6.3× more often per second). L6 sub_82450720 = 24 canary / 16 ours = 4.2×; L7 sub_82451E20 = 90 canary / 80 ours = 5.5×. **Loop-exit-divergence located**: sub_82450720+0x160..+0x1F4 (PC 0x82450880..0x82450914, 5-iter loop bounded by `r25<5`). Ours runs 5/5 iters (80/16=5.00); canary avg 3.75/5 (90/24=3.75) — exits via 0x82450904 `bne` on sub_82451E20's success-predicate match. **Exit predicate**: `[sub_82451E20_out+0]==r30-12 AND [+4]==[r30+0]+[r30+4]` where r30=r26+108+iter*20; data source = 5×20-byte slot table at r26+108..207 (r26=container struct arg1). Predicate fed by sub_82451E20's inner-loop, which dereferences Tier-1 cluster sub_8228E498's `[r3+0][32]`. Bug class **β-data-divergence + γ-deep entry** (sub_821C4988=0 static call xrefs → vtable). **Phase B (300s canary) Tier 2/3 horizon** — ALL 5 PCs (0x82172524, 0x82175810, 0x8217EB78, 0x821A6CF0, 0x821A8578) = **0 fires at 300s**. Cluster activation gated deeper than 5-min Linux Debug horizon (consistent with RECONCILE-A: Linux trace reaches frame 42/186, Lutris Windows reaches 72/186). Tests 640, lockstep instr=100000003. Canary patch reverted; master `9028021` unchanged. **Recommended next**: AUDIT-035 mem-watch r26+108..207 to identify slot-table writer ours misses; OR M5.5 to name sub_821C4988 trigger; OR extended pc-probe of sub_8228E498 capturing `[r3+0][32]` to name predicate compare-target.
- [project_xenia_rs_audit_033_ui_entry_chain_2026_05_08.md](project_xenia_rs_audit_033_ui_entry_chain_2026_05_08.md) — **🎯 KRNBUG-AUDIT-033 (2026-05-08, READ-ONLY, master `9028021`)**: re-applied audit-030 `--log_lr_on_pc` patch (30 LOC, build via `ninja -f build-Debug.ninja xenia_canary`; Checked variant has code-cache alloc collision). Probed 8 PCs (Tier1 cluster externals 0x8228A628/0x8228E138/0x8228E498; Tier2 callers 0x82172524/0x82175810/0x8217EB78; Tier3 CMessageBridge sites 0x821A6CF0/0x821A8578) in BOTH canary (50s wall) and ours (-n 500M). **Convergence**: both fire 0x8228E138 (canary 2× LR=0x82172BF8 in sub_82172BA0, ours 1× same LR) AND 0x8228E498 (canary 28× LR=0x82451E78 in sub_82451E20, ours 62× same LR). **Falsifications**: 0x8228A628 + all Tier 2 + all Tier 3 = 0 fires in canary at 50s — cluster's full activation isn't triggered in canary either at this boot horizon. **Frequency divergence**: ours 62× / 8s guest vs canary 28× / 50s wall on sub_82451E20 — busy-loop in array-ctor dispatch; loop-exit gate is the divergence target. CTOR-PROBE captures full call chain sub_82451E20←sub_82450720←sub_82450638←sub_821CB968←sub_821CD458←sub_821CBEA8←sub_821CECF0←sub_821C4988. Bug class **γ (vtable-driven dispatch)** — both reach Tier 1 entries via same LR; M5.5 (this-flow vptr) prerequisite for deeper top-down probes. Canary patch reverted. Trace `audit-runs/audit-033-ui-entry-chain/{canary-0x*.log,ours.log,ours.err}`. xenia-rs HEAD `9028021` unchanged. **Recommended next**: M5.5 milestone OR pivot to probing sub_82450720/sub_82450638/sub_821CB968 to find loop-exit gate (62 vs 28 fires divergence) OR longer canary trace via Lutris Windows build for post-intro Tier 2+3 activation.
- **🚨 CLUSTER IDENTITY REFRAME (2026-05-08)** — The `0x82285000-0x82294000` cluster (audit-009/016/017/020/021/026/027/029) is **NOT the renderer plateau**. It is the **front-end UI / save-game / mission-select / HUD subsystem** per RAPID-SURVEY-Q4 (93 string refs: BASE_INFO, LOAD_BASES, SAVE_MENUS, MISSION_SELECT, NOW_LOADING, FlightTime, etc.). Past sessions calling this "renderer cluster" or "renderer plateau" misidentified the subsystem. The cluster doesn't fire because the front-end UI flow never *activates*, not because the renderer is broken. The actual renderer (which produces the 2 splash swaps we DO get) lives elsewhere. The `swaps>2 / draws>0` gate is the **front-end loader** — what should activate after intro video → main menu → mission select. **Future sessions: do NOT label this cluster "renderer"**. Add this to running-error ledger as the 11th entry (subsystem-mislabeling class, distinct from the 10 function-boundary entries).
- [project_xenia_rs_overhaul_rapid_survey_2026_05_08.md](project_xenia_rs_overhaul_rapid_survey_2026_05_08.md) — **🎯 RAPID-SURVEY (2026-05-08, READ-ONLY, master `9028021`)**: post-overhaul DB survey of audit-009 cluster `0x82285000-0x82294000`. **Q1 zero**: 6 L1 PCs in NEITHER `methods` NOR `function_pointer_array_entries` (pure `this->vptr` per audit-031/032). **Q2 LEAD**: 13 static arrays at `0x820A9B98-0x820AA024` point INTO cluster; ctor candidates `sub_8228F858, sub_82293EC8, sub_82294898, sub_82284590, sub_822A0860, sub_822A0E90` (all themselves trapped in cluster or adjacent 0x822A0xxx). **Q3 BIG**: cluster has **309 pdata-validated fns, 309 unreachable** via static-call BFS AND indirect-reach view (M5 added 0 edges, ind_call=0 globally). Audit-009's "42 unreached" was 7x undercount. **Q4 PIVOT**: 93 string refs from cluster name **save-game/mission-select/UI subsystem**: BASE_INFO, LOAD_BASES, SAVE_MENUS, AUTO_SAVED, MISSION_SELECT, NOW_LOADING, FlightTime, ClearTimes, Disk free space, Content request — NOT raw renderer. SilpheedSCS::CMessageBridge strings live OUTSIDE cluster (caller `sub_821A6CF0+0xE6C`, `sub_821A8578+0xE0`). **Q5**: 68 cluster fns have `has_eh=true` (heavy C++ EH around save I/O). **Q6**: 0 mis-merge candidates in 0x82200000-0x822F0000 — past audits stand. **Q7**: audit-031 boundary fix verified (sub_824D23B0/29F0/2BD8/2C08 separate). **External entries** sub_8228A628/sub_8228E138/sub_8228E498 ARE called from outside (`sub_82172524, sub_82175810, sub_8217EB78` etc) but THEMSELVES still unreachable in BFS — gate is even higher. **Verdict**: audit-009 framing should pivot from "renderer plateau" to "front-end-UI/save-game cluster never instantiated". M5.5 NOT mandatory before next probe — Q4 already names subsystem; M5.5 would name the trigger ctor. **Recommended next**: `--lr-trace` canary-diff on cluster external-entry PCs + their parents (sub_82172524, sub_82175810, sub_8217EB78); cross-check SilpheedSCS::CMessageBridge::Load/CreateDeviceObjects; schedule M5.5 as next analyzer milestone.
- **✅ ANALYSIS-OVERHAUL FULL CLOSE-OUT (M1-M12 + 5 closers) LANDED (2026-05-08+10)** — [analysis_overhaul_M1_M12](project_xenia_rs_analysis_overhaul_2026_05_08.md). 9 no-ff merges off `e061e21` → master `7bc9e3a`. **All 12 milestones + all 5 deferred closers done.** M1 pdata (12156→25481 fns); M2 demangler; M3 722 vtables/499 anon classes/5571 methods; M4 Class::* probes; M5+M5.5 ind_call (687,963 edges, 97 single-cand + 6,745 multi-cand, **2,746 newly reachable functions** via vptr-write inference — M5.5 surfaces audit-009 cluster); M6+VMX `addr_mode` + 442 x_form_indexed + 40 atomic + 110 stvx; M7+SJIS/UTF-8 strings (6,311 ASCII + 790 SJIS + 39 UTF-8); M8/M11/M11.5 1,110 funcptr arrays (388 dispatch + 0 static_init); M9 has_eh (2,975 fns); M9.5 EH scope-tables (2,588 FuncInfo / 10,019 unwind / 315 try-blocks); M10 .tls infra (Sylpheed none); M12 `--lr-trace` JSONL canary-diff harness. Tests 605→655. Lockstep deterministic at instr=2000005. SCHEMA.md documents all 17 layers + remaining future work (M9.6 EH→function linkage; M11.6 non-canonical static-init drivers; full SJIS→UTF-8 decode; VMX128).
- **🚨 METHODOLOGY CORRECTION (2026-05-08)** — [audit_032_audio_host_pump](project_xenia_rs_audit_032_audio_host_pump_2026_05_08.md) revises audit-025's central claim "audio gate IS renderer gate". They are SEPARATE STALLS. 7+ prior sessions (KRNBUG-018, KE-001, AUDIT-024A/025/026/030/031) chased an audio gate believing it was the renderer gate. The fixes that landed addressed real divergences but did NOT approach `draws > 0`. **Future sessions must NOT re-conflate.** The renderer plateau (audit-009 cluster L1 reachability) is INDEPENDENT and remains the actual `swaps>2 / draws>0` gate. Audio fix is hygiene cleanup; renderer hunt is critical-path. All static analysis avenues for the renderer cluster are exhausted (audit-020/021/026/027/029); next probes need new tooling — analysis-toolset overhaul motivated.
- [project_xenia_rs_methodology_verification_2026_05_08.md](project_xenia_rs_methodology_verification_2026_05_08.md) — **🔍 META-AUDIT (2026-05-08)**: 4 parallel verifications + reconciliations. **VERIFY-A**: 0/12 cluster L1 PCs fire in canary → static reachability BFS is SOUND. **VERIFY-B**: 12/12 PowerPC store classes hooked by mem-watch → coverage COMPREHENSIVE. **RECONCILE-A**: Linux Debug canary kernel-call trajectory IDENTICAL to Lutris Windows; Linux log was simply terminated earlier (frame 42/186 vs 72/186). **RECONCILE-B**: user's "Linux black window vs Windows intro video" is HOST-PRESENTER divergence (Vulkan/XCB-only on Linux; Wayland TODO; H1 swapchain failure most likely; user confirmed Weston also shows black). **Combined verdict**: methodology is sound at kernel-call level. Reading-error ledger (10 entries, mostly function-boundary mis-attribution) is the real motivating gap. Past audit findings stand; no re-grading. Master HEAD `e061e21`, tests 605.
- [project_xenia_rs_audit_032_dispatcher_lr_2026_05_08.md](project_xenia_rs_audit_032_dispatcher_lr_2026_05_08.md) — **🎯 KRNBUG-AUDIT-032 (2026-05-08, READ-ONLY, master `e061e21`)**: re-applied audit-030 `--log_lr_on_pc` canary patch (30 LOC, 4 files), reverted at session close. **7,875 fires** of `pc=0x824D6640` in canary; ALL from single host-flagged kernel thread named **"Audio Worker"** (handle=`0100001C`, native=`467FC6C0`); **LR invariant `0xBCBCBCBC`** = host stack-fill canary, NOT a guest PC. r3=`0x30063000` driver-ctx, r4=0|1 init-vs-tick, r5=`0x1800` frame-size, r6=`0xBDFBA600` callback_arg. Canary log: `XAudioRegisterRenderDriverClient(701CF210(824D6640), BDFBA658(00000000))`. **Mechanism: canary `xe::apu::AudioSystem` (`apu/audio_system.cc:84-159`) spawns host XHostThread "Audio Worker" that loops `WaitAny(client_semaphores_) → processor_->Execute(callback_pc, args)`** — invokes thunk DIRECTLY via host emulator, no guest call site, hence LR=stack-canary. **Falsifies AUDIT-031 vtable[7] hypothesis**: `addi r4, r10, 26176` at sub_824D2C08+0x374 loads PC 0x824D6640 as the callback_ptr ARGUMENT to XAudioRegisterRenderDriverClient (caller-side parameter), not vtable registration. **Outcome δ+α composite**: the "caller PC" we sought is canary's HOST C++, not guest. **Our impl gap**: `XAudioRegisterRenderDriverClient` (exports.rs:2705-2745) registers (callback_pc=0x824D6640, arg=0x41E9DD5C) correctly but **does NOT spawn a host worker thread to pump the callback**, no semaphore-release loop. Probes (`--pc-probe` and `--branch-probe` × 0x824D6640/0x824D29F0) at -n 500M: **0 fires both**. tid=9 parks `pc=0x824D28D0` waiting `0x828A3254`; tid=10 parks `pc=0x824D2990` waiting `0x828A3230` (count=0/limit=6). Bug class **δ-α composite — host-side AudioSystem worker thread missing**. Sharp cascade: A=tid 9 unparks on first sub_824D29F0:KeSetEvent(0x828A3254); B=tid 10 unparks on next sema release; C=XAudioSubmitRenderDriverFrame >0; D=KeReleaseSemaphore non-zero. **Audio gate is NOT renderer gate** (revising audit-025) — separate stalls sharing "host pump missing" symptom only. Tid 10's limit=6 sema = audio-frame queue depth (canary's `queued_frames_=6`), isolated from renderer. Recommended next: implement host-side audio worker (60-120 LOC) per `apu/audio_system.cc`. Won't flip swaps=2→draws>0 plateau alone — audit-025 strategic pivot to audit-009 renderer cluster L1 callers REMAINS priority. Trace `audit-runs/audit-032-dispatcher-lr/{canary-patch.diff, probe.{log,err}, probe-sanity.{log,err}, branchprobe.{log,err}}` + `/tmp/audit-032-canary.log` (7,875 LR fires). Tests 605, lockstep instr=100000003. Master HEAD `e061e21` unchanged.
- [project_xenia_rs_verify_A_canary_pc_trace_2026_05_08.md](project_xenia_rs_verify_A_canary_pc_trace_2026_05_08.md) — **🎯 VERIFY-A (2026-05-08, READ-ONLY, master `e061e21`)**: re-applied audit-030 patch; probed 12 PCs (6 narrow L1 + 6 broader cluster) from audit-009 unreachable cluster `0x82285000-0x82294000` in canary. **0/12 fires** across 35-sec windows while audio loop runs hot (5,600-5,800 KeReleaseSemaphore/window). Sanity-check `0x824D28D0` = 5683 fires confirms trace mechanism. **Outcome (i): static reachability claim is SOUND** — xrefs.kind='call' BFS conclusion is corroborated by canary runtime trace; indirect-dispatch reachability is NOT being missed for this cluster. Audit-009/-016/-017/-020/-021/-029 framing of the cluster as unreachable holds. AUDIT-031's γ-deep dispatcher hypothesis reinforced (the dispatcher exists, but is NOT in this cluster — different code region). 95% upper bound on cluster reach-rate ~22% from sample size; full 112-PC sweep would harden to <5% in ~75 min. Reading-error ledger UNCHANGED (this claim was not on it). Recommended next session: AUDIT-031 sharp-prediction step 1 (probe `0x824D6640`); analysis-toolset overhaul remains motivated by other 10 errors not by this verification. Canary patch reverted. Trace `audit-runs/verify-A-static-reachability/probe-*.log` (13 files).
- [project_xenia_rs_audit_031_audio_wait_site_2026_05_08.md](project_xenia_rs_audit_031_audio_wait_site_2026_05_08.md) — **🎯 KRNBUG-AUDIT-031 (2026-05-08, READ-ONLY, master `e061e21`)**: re-applied audit-030's `--log_lr_on_pc` canary patch (30 LOC, 4 files); reverted at session close. **Outcome (a) — canary EXECUTES PC 0x824D28D0**: 54128 fires in ~5min, audio worker hot-loops through wait→release. Wake source captured via probe of KeSetEvent thunk `0x8284DDDC`: `tid=0100001C lr=0x824D2A44 r3=0x828A3254` = `KeSetEvent(0x828A3254,1,0)` from PC `0x824D2A40`. **AUDIT-025/-030 mis-attribution corrected**: IDA-DB `sub_824D23B0` (claimed range `0x824D23B0..0x824D2878`) actually contains a SECOND function prologue at `0x824D29F0` — that's the real wake-source, NOT sub_824D23B0. sub_824D23B0 entry probe = 0 fires confirms. Static reachability of sub_824D29F0: tail-jump from thunk at `0x824D6640` (which loads `r3=[0x828A3264]`); `0x824D6640` is data-referenced at `sub_824D2C08+0x374` (PC `0x824D2F7C: addi r4, r10, 26176`); next instructions deref `[r31][68]`, load vtable[7] at `[[r3]+28]`, `bcctrl 20,lt` to register the thunk. **Our impl tid=9 state matches AUDIT-025**: `Blocked(WaitAny [0x828A3254]) pc=0x824d28d0`. Bug class **γ-deep, vtable-driven** (refines AUDIT-025 with named downstream witness `sub_824D29F0`). The dispatcher loop that should periodically invoke `0x824D6640` is the unreached gate — likely in `0x82287000-0x82294000` cluster (AUDIT-009). Discipline gate: 5/5 PASS. **Recommended AUDIT-032**: probe `0x824D6640` directly in canary (names dispatcher PC) + probe `0x824D2F90 bcctrl` to capture r3 (audio-engine "this") + vtable[7] address; walk dispatcher's caller chain in our DB; cross-check audit-009 cluster overlap. NO source mods, NO commit. Trace `audit-runs/audit-031-wait-site/{canary-0x824D2878.log, canary-0x824D28D0.log, canary-KeSetEvent.log, canary-sub23B0.log}`.
- [project_xenia_rs_audit_029_physical_mem_diff_2026_05_08.md](project_xenia_rs_audit_029_physical_mem_diff_2026_05_08.md) — **🎯 KRNBUG-AUDIT-029 (2026-05-08, READ-ONLY, master `e061e21`)**: physical-heap diff — LAST guest-memory surface. Architectural finding: our impl has NO separate physical heap (MmAllocatePhysicalMemoryEx folds into v40 bump allocator at 0x40000000+); 0xA0/0xE0/flat-0x00 dumps all `0 committed pages`. Canary physical extracted: 58458 commits / 228 MiB / 24.5 MB nonzero / 28851 0x82xxxxxx PC dwords across 4467 4K pages / 536 64K-regions. **L1 hits: narrow 0/6, broad 2/116 (sub_8228CC18, sub_8228A220 — both scalar, no tables); audit-017 chain 0/8.** **CONFIRMS audit-027 misplacement**: our v40 table at 0x40211900 (18 PCs, 0x20 stride) appears verbatim on canary physical at 0x1c32c910 — same 18 PCs same 0x20 stride same trailing dup. Largest PC run on canary physical: 232 dwords at 0x1e568f38 (XAM/UI 0x824b0xxx-0x824b2xxx family, ~220 PCs); 4 smaller runs ≤9. Top bucket 0x82026000 × 12655 (per-instance vtable in stride-0x38 object array at 0x144x0000). **Outcome ζ — ALL FOUR HEAPS ELIMINATED.** All vtable/dispatch-table hypotheses across audits 010/011/012/015/016/017/026/027/029 refuted. Cluster L1 functions invoked exclusively via static `bl` in unreached parents — gate is upstream of any heap data structure (control-flow gate, not data-population gate). **Strategic pivot mandatory.** Recommended AUDIT-030: Option A (preferred) comparative-execution divergence trace (canary patch periodic tid:pc:lr sample, diff vs ours to find first divergent guest instruction); Option B targeted canary trace logging LR on every entry to sub_824D23B0 (sole KeSetEvent(0x828A3254) caller, vtable-only invoked) to name the per-frame renderer caller; Option C CPPBUG-AUDIT-001 backlog. Discipline gate fails 1. NO source mods, NO commit. Tests 605, lockstep instr=100000003 preserved. Master HEAD `e061e21` unchanged. Trace `audit-runs/audit-029-physical-mem-diff/`.
- [project_xenia_rs_audit_027_v40_mem_diff_2026_05_08.md](project_xenia_rs_audit_027_v40_mem_diff_2026_05_08.md) — **🎯 KRNBUG-AUDIT-027 (2026-05-08, READ-ONLY, master `e061e21`)**: v40 heap byte-level dword diff vs canary's audit-024A 248.6 MiB dump. Captured ours via `--dump-section=0x40000000:0x3F000000` (60119 commits, 1056964608 bytes); extracted canary v40 = 90 commits / 1008 MiB. A-list (canary 0x82xxxxxx, ours differs) = **536**; B-list inverse = 31947. **Cluster L1 (0x82285000-0x82294000) hits = 0/0** broad-and-narrow — v40 ELIMINATED as dispatch-table source (after audit-026 v80 elimination). Top A-list buckets: `0x828f3xxx`(90, .data dispatcher), `0x8284dxxx`(78, .text), `0x8284cxxx`(64, .text near .text-end), `0x82150xxx`(30), `0x828f4xxx`(23), `0x82882xxx`(20). Three vtable-runs detected: `0x40000770` len=32, `0x400015a0` len=110 (same shape, two instances of 110-method class), `0x40000d90` len=20 — all target `.text` heap-allocator handler thunks NOT renderer cluster. Listener anchor `0x40BA9A80` is canary-uncommitted in this dump; ours has audit-016 listener content (`+0x2C=0x4024AC00`, `+0x3C=0x4024B3E0`) — heap-pointer divergent, not missing-write. B-list discovery: `0x40211900..0x40211B50` in OURS has 23 fn-entries spaced 0x20 apart (`0x82183ae8, 0x82187e38, 0x8218cf10, ...`) = a function-table our impl builds in v40 that canary builds elsewhere (likely physical heap). **Strategic pivot mandatory** per task brief outcome (iii). Recommended **AUDIT-029 = extract canary physical heap (0x20000000 span, 58458 commits = 228 MiB)** with same script targeting `physical`. Alt: vtable-write-tap instrumentation. Alt: CPPBUG-AUDIT-001 backlog (`nt_allocate_virtual_memory` silent-success / `mm_allocate_physical_memory_ex` ignores alignment). Trace `audit-runs/audit-027-v40-mem-diff/`. NO source mods; NO commit. Master HEAD `e061e21` unchanged. Sister 028 untouched.
- [project_xenia_rs_audit_028_steady_state_notify_2026_05_06.md](project_xenia_rs_audit_028_steady_state_notify_2026_05_06.md) — **🎯 KRNBUG-AUDIT-028 (2026-05-08, READ-ONLY, canary log + source analysis only)**: XNotify steady-state publisher audit. Canary log (17245 lines) shows ONLY `XamNotifyCreateListener(0x2F)` @1347 + `XNotifyPositionUI(0x0A)` @2018 — NO further notification API calls. `XNotifyGetNext` is `kHighFrequency` (xam_notify.cc:96), per-call logging suppressed. 34 `BroadcastNotification` publisher sites across 11 files in canary; ALL event-driven (host UI, profile change, XMP play, SMC tray, controller hotplug edge) — NONE periodic. Controller hotplug log message absent → no `kXNotificationSystemInputDevicesChanged` fired. `VdSwap` count = 1 (TOC entry only) → ZERO actual swaps in canary; our impl swaps=2 is AHEAD. Audio-sema released 2224× in canary tail. **Outcome β: XNotify queue is NOT the gate**. Our impl matches canary's notification timeline byte-for-byte. The 1.49M `XNotifyGetNext` polls are dutiful idle polling, not missing-publisher symptom. **Strategic pivot: audio/render gate is still the γ-cluster from AUDIT-009/016/017/025** (`sub_824D23B0` via vtable on audio_system `0x82006CF4`, renderer cluster `0x82287000-0x82294000` unreached). AUDIT-029 = static-grep canary for what populates the `0x82006CF4` audio_system vtable at runtime + diff against ours. Provisional cascade A: cluster L1 PC fires; B: KeReleaseSemaphore(0x828A3230) 0→many; C: XAudioSubmitRenderDriverFrame 0→many; D: VdSwap climbs. NO source mods, NO commit, master HEAD `e061e21` unchanged. Trace `audit-runs/audit-028-steady-state-notify/`.
- [project_xenia_rs_audit_025_audio_thread_start_2026_05_06.md](project_xenia_rs_audit_025_audio_thread_start_2026_05_06.md) — **🎯 KRNBUG-AUDIT-025 (2026-05-07, READ-ONLY, master `de5a15e` post-Path-2)**: audio thread-start gate identified as **γ-DEEP, vtable-driven**. XAudioRegisterRenderDriverClient (exports.rs:2705) ≈ canary `xboxkrnl_audio.cc:56-82` semantically; `0x41550000|index` return matches. Audio init `sub_824D2C08` runs to completion in our impl (KeInitializeSemaphore=1 on 0x828A3230 limit=6, ExRegisterTitleTerminateNotification=3, ExCreateThread spawns tids 9 entry=0x824D2878 + 10 entry=0x824D2940, KeResumeThread=2). DISPATCHER_HEADERs correctly populated with Path 2's "XEN\0"+ptr stamp. **Worker correctly parks on `KeWaitForSingleObject(0x828A3254)` waiting for job-submit signal** — but `sub_824D23B0` (the ONLY KeSetEvent(0x828A3254) wake-source, at +0x54/+0x4FC/+0x688) is never reached. Probe set 12 PCs × -n 500M: only `0x824D2DF8` (ExRegTitleTerm in sub_824D2C08) fires; `0x824D23B0`/`0x824D2404` zero fires. **`sub_824D23B0` body at 0x824D2BD8 has ZERO static call-xrefs** — invoked only via vtable on audio_system object (`[r31+0]=0x82006CF4`). Caller would be a per-frame audio update from renderer/scenegraph = the **same `0x82287000-0x82294000` cluster identified by AUDIT-009 as unreached**. Audio gate IS the renderer gate — no new bug class, same γ-cluster blocker. tid 9 state: `Blocked(WaitAny [0x828A3254])` pc=0x824D28D0, signal_attempts=0. Discipline gate fails 1+3. **Recommended next: strategic pivot back to AUDIT-009/016/017's renderer cluster L1 callers + listener vtable population** — what kernel call materializes the listener-dispatch table so renderer can route per-frame audio. Audio worker host-thread emulation is option C (regresses swaps via xaudio-tick path). Trace `audit-runs/audit-025-audio-thread-start/probe.{log,err}`. Master HEAD `de5a15e` unchanged.
- [project_xenia_rs_kernel_stashhandle_2026_05_06.md](project_xenia_rs_kernel_stashhandle_2026_05_06.md) — **🎯 KRNBUG-α-006 (2026-05-07, LANDED branch `xobj-stashhandle/p0-canary-mirror` → master `de5a15e`)**: `ensure_dispatcher_object` (exports.rs:~3097) now writes `+0x08=0x58454E00` (`'X','E','N','\0'` kXObjSignature) and `+0x0C=ptr` (stash handle) per canary `XObject::StashHandle` (xobject.h:253-256). 7 LOC impl + 27 LOC tests. Tests 604→605. Lockstep `instructions=100000003 imports=987516` ×2 reruns (identical to pre-fix d9e40d3 — host-side write). Cascade @ -n 500M: NIL ripple — workers=20, KeReleaseSemaphore=0, XAudioSubmitRenderDriverFrame=0, NtSetEvent=3334, VdSwap=2 all match post-ke-resume baseline. **0x828F4838+0x08 still zeros** at -n 500M because guest never invokes Ke* with that ptr (canary uses `SetNativePointer` lifecycle there, which we don't traverse via `ensure_dispatcher_object`). Audit-024A's hypothesis that this stamp gates audio init is **observationally falsified post-fix**. Lands as canary-correctness restoration (sister of XamUserGetSigninState pattern); no sharp cascade prediction per task brief. Trace `audit-runs/post-stashhandle/`. Next: audio-thread-start gate (post-XAudioRegisterRenderDriverClient) — coordinate with sister AUDIT-025.
- [project_xenia_rs_audit_024a_canary_delayed_trigger_2026_05_06.md](project_xenia_rs_audit_024a_canary_delayed_trigger_2026_05_06.md) — **🎯 KRNBUG-AUDIT-024A (2026-05-07, READ-ONLY, canary patch+rebuild+revert)**: re-applied audit-023's mem-dump pattern with delayed trigger on first `XAudioSubmitRenderDriverFrame_entry` (39 LOC: cpu_flags hunk + xboxkrnl_audio.cc hook). Linux Debug build success after `/home/fabi/xenia-canary` symlink + `--disable_instruction_infocache=true`. Captured 248.6 MiB dump (260,659,200 bytes) at deep boot — canary log shows `KeReleaseSemaphore(0x828A3230,...)` firing repeatedly, VdSwap, VdRetrainEDRAM, texture loads. **AUDIT-017 β-class hypothesis FALSIFIED**: `[0x828F40B0]` (=0x828F4070+64) is **ALL ZEROS in canary** at this post-populator moment, while ours has `-1` sentinel from sub_821701c8. The `[+64]==-1` blocker is not the gate — canary admits `[+64]==0` or takes a different path entirely. **`0x828F4838+0x08` "XEN\0 + 0xF8000034" divergence stable** across audit-023 (early) and 024A (late) triggers — populator wrote it during early init. Heap pointers at `0x828F4838+0x20..0x60` populated in BOTH (canary `0xBC36xxxx`, ours `0x4024xxxx`). `0x828A3230` audio sema has full canary state (`05000000`, "XEN\0+F8000070", count=1, chain to F8000080/F800007C, ts BE628EDC1FCA7000 at +0x38) — KeReleaseSemaphore=0 in ours. Bug class refined β→**γ-deep**: the audio-thread that calls XAudioSubmitRenderDriverFrame is never started in ours despite `XAudioRegisterRenderDriverClient=1` and `KeInitializeSemaphore=1`. Patch reverted (canary `git status` clean). xenia-rs HEAD `d9e40d3` unchanged. Sister AUDIT-024B running in parallel for "XEN\0" writer source-grep. Next: cross-reference 024B's writer with our canary-only export queue (ExTerminateThread/KeReleaseSemaphore) OR α/δ probe of audio-thread-start gate post-XAudioRegisterRenderDriverClient. Trace `audit-runs/audit-024a-canary-diff/`.
- [project_xenia_rs_audit_023_canary_diff_2026_05_06.md](project_xenia_rs_audit_023_canary_diff_2026_05_06.md) — **🎯 KRNBUG-AUDIT-023 (2026-05-06, READ-ONLY, Path B canary patch+rebuild+revert)**: temp 44-LOC canary patch (cpu_flags + xam_notify) added `--memory_dump_path` flag, dumped 216 MB on first XamNotifyCreateListener (mask=0x2F). Linux Debug build success after `--disable_instruction_infocache=true` workaround for canary's pre-existing XexInfoCache SIGBUS. PageEntry `state` bitfield empirically at qword bits 60-61 (NOT declaration-order 48-49). Canary's first-listener dump shows v80=146 committed pages but 0x828F4070 area ALL ZEROS (too-early trigger — populator hadn't run). Diff vs ours @-n 50M reveals: (1) `0x828E1F08` ours has listener pointer 0x40111890, canary=0 (mechanism difference, ours stuffs guest-mem, canary uses host-side notify_listeners_ vector); (2) **`0x828F4838+0x08` canary has ASCII `"XEN\0"` + handle `0xF8000034`, ours has zeros — NEW POPULATOR-EFFECT LEAD inside audit-016/017 cluster**; (3) `0x82124xxx` audit-009 cluster L1 PCs visible as data — REFUTED as populator target, this is static .pdata exception table, byte-identical in ours; (4) various `0xBC...` host-physical aliases vs ours `0x40...` virtual aliases (handle-namespace difference, not bug). **Audit-017 β-class hypothesis NEITHER confirmed NOR refuted** (canary trigger too early). Patch reverted (`git status` clean). Trace `audit-runs/audit-023-canary-diff/canary-memory.dump,canary-patch.diff,parse_dump.py,diff.txt`. Master HEAD `d9e40d3` unchanged. Next: AUDIT-024 either re-apply with later trigger (Nth listener / first XAudioSubmitRenderDriverFrame / first NtSetEvent on specific event) for fair like-for-like, OR static-search canary's xboxkrnl source for "XEN\\0" writer at 0x828F4840 (names populator's CODE).
- [project_xenia_rs_kernel_ke_resume_thread_2026_05_06.md](project_xenia_rs_kernel_ke_resume_thread_2026_05_06.md) — **🎯 KRNBUG-KE-001 (2026-05-06, LANDED branch `ke-resume-thread/p0-canary-mirror`)**: real `KeResumeThread` per canary `xboxkrnl_threading.cc:216-227` (mirrors nt_resume_thread plumbing). 600→601 tests; lockstep `instructions=100000003 imports=987516` ×2. **Cascade A PASS**: tids 9 (entry=0x824D2878) / 10 (entry=0x824D2940) leave Suspended → run prologue → park on audio buffer-completion semaphores 0x828A3254 / 0x828A3230. **B PARTIAL FAIL**: NtSetEvent 667→3334; KeReleaseSemaphore=0; XAudioSubmitRenderDriverFrame=0. **C FAIL** (predicted 2→1, actual 2→2): both ExTerminateThread + KeReleaseSemaphore still canary-only. **D FAIL**: γ-cluster blocker unchanged — `--pc-probe=0x82184318,0x82184374` no fires; `--dump-addr=0x828F4070` no DUMP; signal_attempts on 0x1004/0x100c/0x1020/0x15e4 still 0. swaps=2 draws=0 plateau intact. Goldens re-baselined `n50m: instructions 50000003→50000011, imports 407255→407247`. **Necessary-but-not-sufficient fix**: workers unsuspend but park on a downstream gate that's part of the audit-009/-016/-017 γ-cluster (`[0x828F4070+64]==-1`). Trace `audit-runs/post-ke-resume/`. Next: AUDIT-019 memory-watch on `[0x828F4070+64]` (audit-017 Option B).
- [project_xenia_rs_audit_018_canary_diff_2026_05_06.md](project_xenia_rs_audit_018_canary_diff_2026_05_06.md) — **🎯 KRNBUG-AUDIT-018 (2026-05-06, READ-ONLY)**: canary-log diff identifies α-class load-bearing stub. Function-name set-diff: only 2 calls in canary not in ours — `ExTerminateThread`, `KeReleaseSemaphore`. The latter is hammered by canary tid `F800006C` (audio render-frame ticker, entry=0x824D2878, ctx=0, flags=0x10000001) which canary unsuspends via `KeResumeThread(KTHREAD_ptr)`. **Our `ke_resume_thread` (exports.rs:3658-3664) is a no-op stub that ignores r3 and sets r3=0** — comment claims `nt_resume_thread` covers it, but `KeResumeThread` is a separate export. Canary `xboxkrnl_threading.cc:216-227` calls `thread->Resume()`. **Result: tids 9 (entry=0x824D2878) and 10 (entry=0x824D2940) are `Blocked(Suspended)` at -n 500M end-of-run** despite our `KeResumeThread=2` counter matching canary. Bug class **α (load-bearing stub_success)**. **All 5 discipline boxes pass — first time since IO-004**. Fix is 5 LOC (mirror nt_resume_thread pattern). Sharp 4-dim cascade prediction: A=tids 9/10 leave Suspended; B=KeReleaseSemaphore non-zero; C=2→1 canary-only; D=open hypothesis on `[0x828F4070+64]` becoming non-(-1) if β-blocker is downstream of audio init. Trace `audit-runs/audit-018-canary-diff/ours.{log,stdout.log}`. Master HEAD `7ed6192` unchanged. Next: KRNBUG-α-005, branch `ke-resume-thread/p0-canary-mirror`.
- **XamUserGetSigninState landed (2026-05-06, master `7ed6192`)** — small canary-mirror fix at xam.rs:48 (returns 1 for user 0 per `xam_user.cc:90-101`). Tests 599→600. Lockstep `instructions=100000006` deterministic ×2 reruns (was 100000012). Cascade ripple: `XamUserReadProfileSettings` now fires 2× (was canary-only). Canary-only kernel exports: 3→2 (still missing: ExTerminateThread, KeReleaseSemaphore). β-class blocker `[0x828F4070+64]==-1` unmoved per audit-017. swaps=2 draws=0 plateau intact.
- [project_xenia_rs_audit_017_state_bits_writer_2026_05_06.md](project_xenia_rs_audit_017_state_bits_writer_2026_05_06.md) — **🎯 KRNBUG-AUDIT-017 (2026-05-06, READ-ONLY)**: 5 static bit-14/15 setters of `[listener+4]` found; case-0xA `0x82173e04` sets bit-15 once at cycle 9183060, sub_821737F0 work-path enters at 9183561, but bit-14 setter at 0x82173950 NEVER fires — gated at 0x821738E0 by `[r30+64]==-1` where r30=`[0x828F48B0+0]=0x828F4070` (singleton sub-object). `[+64]` initialized to -1 by sub_821701c8; only non-(-1) writer is sub_82184318:0x82184374 (`bl 0x82456B58 (kernel handle); stw r3, 64(r30)`); chain bottoms in audit-009 cluster (`sub_82187dd0 ← sub_82183ca8 ← sub_822919c8`). bit-28 of `[singleton+60]` set at cycle 9224352 by sub_821c4988 — too late, AND is a NEGATIVE gate. Bug class **β-dominant + α-tail** (`XamUserGetSigninState=stub_return_zero` at xam.rs:48 breaks 2 separate guest paths but won't fire cascade alone). Discipline gate fails 1+3. No fix. Trace `audit-runs/audit-017-state-bits-writer/probe{1..5}.log`. Master HEAD `d736a1d` unchanged. Next: AUDIT-018 either probe-confirm sub_82184318 chain (3rd γ-cluster confirmation → strategic pivot) or canary-log-diff for missing kernel writer of `[0x828F4070+64]`.
- [project_xenia_rs_audit_016_submitter_callers_2026_05_06.md](project_xenia_rs_audit_016_submitter_callers_2026_05_06.md) — **🎯 KRNBUG-AUDIT-016 (2026-05-06, READ-ONLY)**: 0/16 submitter-chain PCs fire at -n 500M across 4 levels of caller walk-up (workitem chain `sub_822AE1F0/sub_822F55F0 → sub_822C8B50 → sub_822C6808` + parents `sub_822ADD70/sub_821A9920/sub_822ACAB8/sub_821A8578` + grandparents `sub_82299250/sub_822A4460/sub_821A82A0`). Both static caller chains bottom-out in audit-009 unreached renderer cluster (`0x82294xxx` / `0x821A6xxx`). Listener-struct dump at `0x40ba9a80`: vtable populated, callback-table A `[+0x2C]=0x4024AC00` POPULATED (audit-015's "==0" claim was WRONG), callback-table B `[+0x3C]=0x4024B3E0` POPULATED, but `[+0x04]` dispatch-state-bits=0 — real gate is `sub_821737F0`'s bit-14/15 read of [+4]. Bug class refined δ→**γ (deeper indirection)**: chicken-and-egg vtable-registry-not-populated. Discipline gate fails 1+3. Probe-machinery anomaly: `sub_82174040` entry never fires despite mid-body PC executing — verify in AUDIT-017. Next: probe `sub_822F1AA8` frame-poll + writers of `[0x40ba9a80+4]` + `sub_82181D48` predicate. Trace `audit-runs/audit-016-submitter-callers/probe{,2}.{log,err}`. Master HEAD `d736a1d` unchanged.
- [project_xenia_rs_audit_015_l1_propagation_2026_05_06.md](project_xenia_rs_audit_015_l1_propagation_2026_05_06.md) — **🎯 KRNBUG-AUDIT-015 (2026-05-06, READ-ONLY, FORK B)**: 28/112 PCs fired at -n 500M post-IO-004. sub_82173DC8 dispatches all 4 startup notifications then idles via early-exit at 0x82173ed8 (`[r31+44]==0` callback-table NULL). Worker 0x822c6870 (tids 14, 15) parks on Semaphore handle 0x1308 (`signals=0 waits=2`); producer chain `sub_822AE1F0/sub_822F55F0 → sub_822C8B50 → sub_822C6808 → 0x824AB158 (NtReleaseSemaphore)` is unreached. Worker sub_824563E0 (tid=16) is healthy XAM inactivity-poll loop; not the gate. Worker sub_823DDB50 (tid=19) parks at entry on 0x160C Event/Auto. All 21 audit-009 baseline PCs still UNFIRED. Bug class **δ (pure-guest renderer)** — no kernel boundary stub. Discipline gate fails 1+3, no fix. Next session: probe submitter chain entries + `--dump-addr=0x40ba9a80` listener struct. Trace `audit-runs/audit-015-l1-propagation/`. Master HEAD `d736a1d` unchanged.
- [project_xenia_rs_audit_014_0x15e0_wake_2026_05_06.md](project_xenia_rs_audit_014_0x15e0_wake_2026_05_06.md) — **🎯 KRNBUG-AUDIT-014 (2026-05-06, READ-ONLY)**: 0x15e0 wake-eligibility hypothesis FALSIFIED. 0x15e0 is a Semaphore (creator `lr=0x824ab110`), `signal_attempts=1 waits=1 wakes=1`, healthy handshake (tid=1 wait → tid=16 NtReleaseSemaphore wake). tid=17 actually parks on **0x15e4** (Event/Manual, signals=0/waits=1/wakes=0, creator `lr=0x824a9f6c`) — same producer-missing class as 0x1004/0x100c/0x1020. Long-standing transcription error: AUDIT-002/008/009/IO-004 label "0x15e0 worker" should be "0x15e4 worker". Bug classes α-ζ all N/A. Discipline gate fails box 1. No fix. Master HEAD `d736a1d` unchanged. Trace `audit-runs/audit-014-0x15e0-wake/probe.{log,err}`. Next: Fork B branch-probe data on `sub_82173DC8 / 0x822c6870 / 0x824563e0 / 0x823ddb50` for the actual producer.
- [project_xenia_rs_io_004_xnotify_listener_2026_05_06.md](project_xenia_rs_io_004_xnotify_listener_2026_05_06.md) — **🎯 KRNBUG-IO-004 (2026-05-06, LANDED branch `xnotify-listener/p0-startup-enqueue`)**: real `XamNotifyCreateListener` + `XNotifyGetNext` per canary `kernel_state.cc:1013-1033` + `xam_notify.cc:22-96`. NotifyListener variant + 4 startup notifications on first listener (mask 0x2F): SystemUI/SystemSignInChanged on kXNotifySystem; LiveConnectionChanged(0x001510F1)/LiveLinkStateChanged on kXNotifyLive. 594→599 tests; lockstep `instructions=100000012` deterministic ×2 reruns. Phase 1.5 sanity probe confirmed CTR=0x82175338 (audit-012-predicted dispatch target unchanged). **Cascade: dispatch arm 0x822f1be8 fires; sub_82173DC8 entered repeatedly; 3/21 renderer-cluster L1 PCs newly reached (0x822c6870 from 2 workers, 0x824563e0, 0x823ddb50)**; canary-only 7→3 (KeResetEvent/ObCreateSymbolicLink/XamTaskCloseHandle/XamTaskSchedule re-classified to fired; still missing: ExTerminateThread/KeReleaseSemaphore/XamUserReadProfileSettings); worker count 18→20; signal_attempts on 0x15e0=1 (primary=1, was 0); draws=0 still expected at this step. LOC 119 ≤ 120. Trace `audit-runs/audit-013-io-004-phase1.5/`.
- [project_xenia_rs_cpp_runtime_audit_2026_05_06.md](project_xenia_rs_cpp_runtime_audit_2026_05_06.md) — **🔍 CPPBUG-AUDIT-001 (2026-05-06, READ-ONLY, BACKGROUND-BACKLOG)**: 0x825ED990 = CRT abort dispatcher (NOT _purecall — corrects audit-010); Sylpheed CRT is statically linked. Top-3 vtable=0 candidates REFUTED by audit-012. Real gaps for later: nt_allocate_virtual_memory silent-success-on-error (exports.rs:622-625) + heap.rs:465 silent-unmapped-write drop (combined = "phantom allocation"); mm_allocate_physical_memory_ex ignores alignment/range/protect; sync/eieio interpreter no-ops; RtlRaiseException stub doesn't fatal-stop on MSVC throws. Track for after draws>0.
- [project_xenia_rs_audit_012_vtable_zero_2026_05_06.md](project_xenia_rs_audit_012_vtable_zero_2026_05_06.md) — **🎯 KRNBUG-AUDIT-012 (2026-05-06, READ-ONLY)**: ALL FIVE bug-class hypotheses for vtable=0 REFUTED. Vtable IS correctly initialized: mem[0x40111890+0] transitions monotonic 0→0x820AD894→0x820A183C, stays. AUDIT-011's "vtable=0" was a misread (captured PC 0x8284E45C XAM thunk, treated lwz address as live PC). AUDIT-010's "vtable[1]=0x825ED990 abort" was the inner ctor's transient vtable, overwritten 3 instructions later. Real runtime vtable[1] = thunk 0x82175338 → sub_82173DC8. Discipline gate now PASSES for AUDIT-011's listener fix. Next: KRNBUG-IO-004 (real xnotify queue per kernel_state.cc:1013-1033 + xam_notify.cc) with Phase 1.5 sanity probe at 0x822f1c00 (expect CTR=0x82175338) before commit.
- [project_xenia_rs_audit_010_xnotify_diff_2026_05_05.md](project_xenia_rs_audit_010_xnotify_diff_2026_05_05.md) — **🎯 KRNBUG-AUDIT-010 (2026-05-05, READ-ONLY)**: branch (α) — xnotify_get_next + xam_notify_create_listener are stubs; canary auto-enqueues 4 startup notifications on listener registration (SystemUI/SystemSignInChanged/LiveConnectionChanged/LiveLinkStateChanged). Discipline gate FAILS box 3: vtable[1] of dispatcher (mem[0x828E1F08]) statically=0x825ED990 abort handler — needs runtime --pc-probe before fix. Provisional cascade: XamUserReadProfileSettings fires next. Trace `audit-runs/audit-010/findings.md`. Master HEAD `50a4887` unchanged.
- [project_xenia_rs_audit_009_renderer_unreached_2026_05_05.md](project_xenia_rs_audit_009_renderer_unreached_2026_05_05.md) — **🎯 KRNBUG-AUDIT-009 (2026-05-05, READ-ONLY DIAGNOSTIC)**: 0/21 PCs fired at -n 500M (12 audit-008-recommended renderer-cluster parents+shims+dispatcher + 9 audit-005 producer-callsites). Stop condition 1 triggered. The 0x82287000-0x82294000 cluster is structurally above its observed call boundary — likely reached via vtable/function-pointer that's never populated (sylpheed.db: zero non-call xrefs to its level-1 roots `sub_82293448`/`sub_822919C8`). Main parks in `sub_822F1AA8` frame-poll loop forever (XNotifyGetNext=1.49M, NtWaitForSingleObjectEx=1.49M, RtlEnter/LeaveCS=889k each). 18 workers spawned incl. 0x100c (tid=3, ctx=0x828F3D08), 0x1004 (tid=11, ctx=0x828F3EC0), 0x15e0 (tid=17, ctx=0x828F4070) — all parked, signal_attempts=0. canary-only exports unchanged: ExTerminateThread/KeReleaseSemaphore/XamUserReadProfileSettings. Discipline gate fails boxes 1+3. No fix. Next probe set: cluster L1 roots (sub_82293448/sub_822919C8/sub_82288028/sub_82292d80/sub_822851e0/sub_82286bc8) + new thread entries (0x822c6870/0x824563e0/0x823dde30/0x823ddb50) + main frame-poll callees + main's post-poll continuation (sub_822F1638/sub_8216F088/sub_82173360 etc). Trace at `audit-runs/audit-009/probe-500m.{log,err}` (branch-probe.trace EMPTY).
- [project_xenia_rs_audit_008_branch_probe_2026_05_05.md](project_xenia_rs_audit_008_branch_probe_2026_05_05.md) — **🎯 KRNBUG-AUDIT-008 (2026-05-05, READ-ONLY DIAGNOSTIC)**: Model reset on IO-003 cascade. 0x100c worker IS spawned post-IO-003 (tid=3, ctx=0x828F3D08, entry=0x82181830, parked on event 0x1020). Same for 0x1004 (tid=11), 0x15e0 (tid=6). Real next gate is β-class: 5 non-create-chain callers of `sub_821800D8` (shims `bl getter; lwz r3,80(r3); bl sub_824AA1D8` at 0x821802D8/06E0/0B28/0EA0/1254) are never called; parents live in 0x82287000-0x82292FFF (renderer/scene-graph). **AUDIT-009 falsified the audit-008 hypothesis: those parents are themselves not entered — gate is one level higher still.** Discipline gate failed boxes 1+4. Trace at `audit-runs/audit-008/`.
- [project_xenia_rs_io_003_ioctl_2026_05_04.md](project_xenia_rs_io_003_ioctl_2026_05_04.md) — **🎯 KRNBUG-IO-003 (2026-05-04, LANDED branch `xboxkrnl-ioctl/p0-fsctl-mountinfo`)**: `nt_device_io_control_file` real impl per canary `NullDevice::IoControl` for FsCtlCodes 0x70000 + 0x74004. **Cascade fired**: priv-11 query runs, XamTaskSchedule fires, canary-only exports 7→3, AND 0x100c worker (tid=3, ctx=0x828F3D08) + 0x1004 worker (tid=11, ctx=0x828F3EC0) + 0x15e0 worker (tid=17, ctx=0x828F4070) all spawn (the original IO-003 prediction-scorecard's "0x100c UNCREATED / spawn count unchanged" marks were wrong per AUDIT-008 — workers were always there post-IO-003, just unlinked from dispatcher addresses in the audit). 592→594 tests; lockstep deterministic. Stack args 9-10 land at `[sp+0x54]` / `[sp+0x5C]` (Xbox 360 PPC EABI param save area = sp+0x14 + 64). `sylpheed_n50m` re-baselined `50000004→50000003`, `imports 407362→407255`. Still canary-only: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`. **All 3 workers parked, signal_attempts=0** — the producer-side cascade is downstream of where IO-003 reaches; AUDIT-008 + AUDIT-009 trace it to the unreached 0x82287-0x82294 renderer cluster.
- [project_xenia_rs_audit_007_branch_probe_2026_05_04.md](project_xenia_rs_audit_007_branch_probe_2026_05_04.md) — **🎯 KRNBUG-AUDIT-007 (2026-05-04, READ-ONLY branch `investigate-sub-824a9710/p0-branch-probe`)**: `--branch-probe` instrumentation landed; runtime trace decisively identifies the priv-11 gate. **Exit branch: `0x824a9944` (post-bl sub_824ABD88 first call, r3=0xC0000034)**. Root cause: `NtDeviceIoControlFile` is `stub_success` at `exports.rs:90` — game-side `sub_824ABD88:0x824abe9c-eb0` reads `[out_buf+8]` of the FsCtlCode=0x74004 IOCTL response, finds zero (stub doesn't write OUT), assigns hardcoded `r3=0xC0000034` (STATUS_OBJECT_NAME_NOT_FOUND) at 0x824abea8-ac, propagates to caller, gates priv-11 site at `0x824a99a0` indefinitely. 592→592 tests, lockstep deterministic. **Next session = KRNBUG-IO-003**: implement `nt_device_io_control_file` per canary `NullDevice::IoControl` for FsCtlCodes 0x70000 + 0x74004. Predicted cascade: priv-11 fires + XamTaskSchedule fires + 0x100c worker spawn + 7→≤3 canary-only exports.
- [project_xenia_rs_io_002_volallocunit_2026_05_04.md](project_xenia_rs_io_002_volallocunit_2026_05_04.md) — **🎯 KRNBUG-IO-002 (2026-05-04, LANDED branch `xboxkrnl-vol-allocunit/p0-65536-cluster`)**: vol-info class-3 fixed from 2048→65536 alloc unit (canary NullDevice byte-identical). 591→592 tests, lockstep deterministic. **Audit-006's predicted 7→0 cascade FALSIFIED** (7→7 unchanged): all 16 NtQueryVolumeInformationFile calls originate from a single LR `0x82611f38` and complete successfully — vol-info is NOT the priv-11 gate. Stop condition triggered, no second fix attempted. Next session: `--pc-probe` on `sub_824A9710` entry to find the actual gate (priv-11 site has never fired in any session).
- [project_xenia_rs_audit_006_export_queue_2026_05_04.md](project_xenia_rs_audit_006_export_queue_2026_05_04.md) — **🎯 KRNBUG-AUDIT-006 (2026-05-04, READ-ONLY)**: 7/7 canary-only exports all REAL_BUT_UNREACHED → next session is **KRNBUG-IO-002** (block-size 2048→65536 in `exports.rs:1241-1269`, ≤4 LOC). Queue: `xenia-rs/audit-runs/audit-006/canary_export_queue.md`. **Cascade prediction FALSIFIED post-IO-002 — see io_002 memory.**
- [project_xenia_rs_io_nullfile_2026_05_04.md](project_xenia_rs_io_nullfile_2026_05_04.md) — **🎯 KRNBUG-IO-001 (2026-05-04, LANDED master `556a8c3`)**: `nt_read_file` on synth-empty files returns SUCCESS+0 instead of EOF, mirroring canary `NullFile::ReadSync`. AUDIT-005's attribution to `sub_824ABA98` was wrong — runtime trace decisively located the failure at the `NtReadFile(\Device\Harddisk0\partition0, off=2048, len=1024)` call inside `sub_824A9710` at PC `0x824a9810`. **`sub_824ABA98 = VerifyDirBlockSize(path, expected_alloc_unit_bytes)`**, **`sub_824ABD88 = MaybeMountAndIoctl`** (NtOpenFile WindowsPartition + NtDeviceIoControlFile 0x70000+0x4004). 590→591 tests. Lockstep BIT-IDENTICAL × 3 reruns. **Cascade walked massively: canary-only exports 10 → 7** (XeCryptSha + XeKeysConsolePrivateKeySign + NtDeviceIoControlFile now run; cache-recreate path executes through to NtWriteFile). Worker threads **6 → 19** at -n 500M (tid=10 `0x82178950` and tid=16 `0x82170430` — the original `0x1004`/`0x15e0` workers — now spawn). `n50m` golden re-baselined `50000004→50000000`, `imports 407416→407362`. **Next blockers**: (1) XamTaskSchedule cluster + ExTerminateThread/KeReleaseSemaphore/KeResetEvent/ObCreateSymbolicLink/XamTaskCloseHandle/XamUserReadProfileSettings — the 7 still-canary-only exports; (2) **block-size mismatch**: `nt_query_volume_information_file` returns `SectorsPerAllocUnit=1, BytesPerSector=2048` (=2048) but Sylpheed expects `0x10000=65536` from `main(1, 0x10000, 0xFF000)` → `sub_824A9710 r27=0x10000`; sub_824ABA98 will return `0xC000014F` when the recreate path eventually reaches it. New parked sites: 0x12fc/0x1600/0x1040/0x10b8/0x15e8/0x1014/0x101c/0x10bc/0x1044 + 0x42450b5c. `swaps=2 draws=0` plateau persists.
- [project_xenia_rs_xam_avpack_hdmi_2026_05_04.md](project_xenia_rs_xam_avpack_hdmi_2026_05_04.md) — **🎯 KRNBUG-XAM-001 (2026-05-04, LANDED)**: `XGetAVPack` `0x16` → `8` (HDMI). One-line at `xenia-kernel/src/xam.rs:383` mirroring canary `xam_info.cc:35` (`DEFINE_int32(avpack, 8)`); Sylpheed accepts `{3,4,6,8}` only (`xam_info.cc:250-251`). 589→590 tests. Lockstep deterministic across 3 reruns: `instructions=100000010, import_calls=987686 (+2.4×), VdSwap=2`; `n50m` golden re-baselined `50000005→50000004`. **Canary diff: 11 → 10 missing exports** (XGetAVPack matched). Cascade went exactly **one step**. **NEW telemetry signal**: `RtlNtStatusToDosError(c0000011)` from `lr=0x824a97e4` post-fix — `sub_824A9710` IS being entered now but priv-11 query never fires (a precondition exits early). **Next blocker: `sub_824ABA98` returning negative NTSTATUS** (per AUDIT-005 disasm); if cleared, `XeCryptSha`/`XeKeysConsolePrivateKeySign`/`NtDeviceIoControlFile`/etc. should follow. Parked handles 0x1004/0x100c/0x15e0 still `signal_attempts=0`; 9-PC producer probe still 0×; `swaps=2 draws=0` plateau persists.
- [project_xenia_rs_xex_priv_fix_2026_05_04.md](project_xenia_rs_xex_priv_fix_2026_05_04.md) — **🎯 KRNBUG-XEX-001 (2026-05-04, LANDED)**: real `XexCheckExecutablePrivilege` reading XEX `SYSTEM_FLAGS=0x00030000` bitmap (Sylpheed=`0x00000400`, bit 10 set). 588→589 tests. Lockstep deterministic at new value (`instructions=50000005, imports=407417, swaps=2, draws=0` × 3 reruns). Goldens re-baselined. **Priv-10 gate FLIPPED** — `XGetAVPack: 0→1`. Other 10 canary-only exports + 9 producer PCs + 3 parked handles still unchanged: priv-11 site at `sub_824A9710` is downstream and not reached because the AV/crypto block aborts after `XGetAVPack`. **Next blocker: `XGetAVPack` returns `0x16`** — canary returns `cvars::avpack` (default 8 = HDMI), and Sylpheed accepts only 3/4/6/8 (xenia-canary `xam_info.cc:250-251`). One-line follow-up at `xenia-kernel/src/xam.rs:383`.
- [project_xenia_rs_audit_005_priv_stub_2026_05_04.md](project_xenia_rs_audit_005_priv_stub_2026_05_04.md) — **🎯 KRNBUG-AUDIT-005 (2026-05-04, LANDED master `451b3b2`)**: --pc-probe extension + canary kernel-call diff. 9 producer PCs unreached at -n 500M (failure mode α). **Root cause: `XexCheckExecutablePrivilege` is `stub_return_zero`** — gates XGetAVPack (priv=10) and XamTaskSchedule (priv=11) via opposite polarities, so guest walks wrong arm of every priv-gated branch and skips the entire init flow that populates dispatcher fields. 11 exports canary calls and we don't (XGetAVPack/XeCryptSha/XamTaskSchedule/...). Next: implement real priv-bit lookup from XEX header.
- [project_xenia_rs_audit_004_ctor_probe_2026_05_04.md](project_xenia_rs_audit_004_ctor_probe_2026_05_04.md) — **🎯 KRNBUG-AUDIT-004 (2026-05-04, LANDED master `6a070be`)**: read-only `--ctor-probe=PC` + `--dump-addr=ADDR` diagnostics; 586→588 tests; lockstep `instructions=100000002` preserved. **DECISIVE: "8-instance pool" hypothesis FALSE** — handle 0x1004 has a SINGLE dispatcher at `0x828F3EC0`; inner per-instance ctors `[0x821783D8,0x82181750,0x821701C8]` each fire EXACTLY ONCE. The "called 8 times" claim from AUDIT-002/003 came from miscounting OUTER getter `sub_8217C850` entries — itself a Meyers singleton-getter. **Producer indirection layer IDENTIFIED**: outer getters `sub_821800D8` (0x100c) and `sub_8216F618` (0x15e0) have 5+4 non-create-chain callers using canonical pattern `bl outer_getter; lwz r3, OFFSET(r3); bl 0x824AA1D8` (OFFSET=80 for 0x100c, =36 for 0x15e0). Static byte-scan of .rdata/.data shows 0 hits → no registry table; indirection is via the singleton-getter return value. **Interpretation (2) confirmed.** 9 producer-callsite PCs ready for next-session probe to discriminate failure mode A (producer never reached) from B (producer fires but reads zero from dispatcher field). Files: `crates/xenia-kernel/src/state.rs` (`fire_ctor_probe_if_match`, `ctor_probe_pcs`, `dump_addrs`), `crates/xenia-app/src/main.rs` (CLI wiring + 128-byte struct dumper). Trace at `audit-runs/audit-004/`.
- [project_xenia_rs_audit_003_class_probe_2026_05_03.md](project_xenia_rs_audit_003_class_probe_2026_05_03.md) — **🎯 KRNBUG-AUDIT-003 (2026-05-03, LANDED master `48eed25`)**: vtable/RTTI class-readout helper + create-time + wait-time per-frame class probes. 581→586 tests; lockstep `instructions=100000002` preserved. **Identified dispatcher addresses**: handle 0x100c → `0x828F3D08` (verified by `[this+0]=-1` POD struct + sub_82181750 disasm + xref table); handle 0x15e0 → `0x828F4070` (xref table). RTTI is **stripped**; dispatchers are hand-rolled job queues, NOT C++ polymorphic classes (so no class names — `[this+0]=-1` sentinel, not a vtable). **Producer hunt deliverable**: `xrefs` table audit shows EVERY reference to 0x828F3D08 / 0x828F4070 is in a ctor or the CRT — NO submitter code references either dispatcher in static analysis. Confirms unreachable-producer hypothesis. Handle 0x1004's 8-instance pool member addresses still need offline analysis (saved-r31 in MSVC ctors didn't preserve `this`; need to hook sub_8217C850 to capture each pool element's r3). 0x42450b5c remains a separate bug class (heap-allocated, AUDIT_BLIND). Files: `crates/xenia-kernel/src/state.rs` (`read_class_at_this`, `probe_create_stack_classes`), `crates/xenia-app/src/main.rs` (WAIT-side dump). Trace at `audit-runs/audit-003/run-500m-v4.txt`.
- [project_xenia_rs_producer_stack_trace_2026_05_03.md](project_xenia_rs_producer_stack_trace_2026_05_03.md) — **🔍 KRNBUG-AUDIT-002 (2026-05-03, LANDED master `6440261`)**: multi-frame back-chain capture at `NtCreateEvent`/`NtCreateSemaphore`/`NtCreateTimer`/`XamTaskSchedule` gated on `--trace-handles-focus`; 576→581 tests; lockstep `sylpheed_n50m` BIT-IDENTICAL. **Subsystems identified**: 0x1004 = static-ctor 8-instance pool (sub_821783D8 + sub_8217C850 chain → static ctor 0x8280F810 calls bridge 8×); 0x100c = singleton built inside main() (sub_8216EA68 = main); 0x15e0 = singleton in distinct cluster (sub_82172BA0 chain). All 3 ctors share identical 4-callee shape (Rtl InitCS + silph::Event ctor + silph internals); all 3 workers do `silph::Thread::SetProcessor(CURRENT,5)` first thing. **Corrections to prior memory**: (1) third handle is **0x15e0**, not 0x15e4 (transcription typo); (2) **0x42450b5c is not a kernel handle** — it's a guest-heap pointer (0x4xxxxxxx), tid=6 parks via a non-`do_wait_single` path (`<UNCREATED> <AUDIT_BLIND>`) — separate bug class. Walker is in `state.rs::walk_guest_back_chain` (PPC EABI back-chain, gated, read-only).
- [project_xenia_rs_xaudio_register_driver_2026_05_03.md](project_xenia_rs_xaudio_register_driver_2026_05_03.md) — **🎯 APUBUG-PRODUCER-001 (2026-05-03)**: XAudio register stub replaced with canary-faithful registration + dual-mode ticker (`XAUDIO_INSTR_PERIOD=48k` / `XAUDIO_PERIOD=5.333ms`) + `try_inject_audio_callback` reusing SavedCallbackCtx; 562→576 tests. Ticker gated **default-off** behind `--xaudio-tick`/`XENIA_XAUDIO_TICK=1` so lockstep `sylpheed_n*m.json` goldens stay green. **Producer hypothesis FALSIFIED for handles 0x1004/0x100c/0x15e4** — at `-n 500M --xaudio-tick` all 3 still show `signal_attempts=0`. Side-effect: under the flag the audio callback fires once, hijacks a guest HW thread on a `KeWaitForSingleObject` infinite loop (4M waits, swaps regress 2→1). Next candidate: **Timer DPC** (`KeSetTimer` / `KeInsertQueueDpc`). Master HEAD `9d45efe`.
- [project_xenia_rs_xam_task_schedule_2026_05_03.md](project_xenia_rs_xam_task_schedule_2026_05_03.md) — **🎯 XAMBUG-PRODUCER-001 (2026-05-03)**: XamTaskSchedule stub replaced with canary-faithful real spawn; 561→562 tests; lockstep `instructions=100000002` preserved. **Producer hypothesis FALSIFIED for handles 0x1004/0x100c/0x15e4** — counter `kernel.calls{XamTaskSchedule}` never appears at -n 500M (call site `0x824a9a10` unreached). Boot stalls before XamTaskSchedule. Next candidate: `XAudioRegisterRenderDriverClient` (counter=1, currently stub). Master HEAD `38f78c8`.
- [project_xenia_rs_audit_2026_05_followup_session.md](project_xenia_rs_audit_2026_05_followup_session.md) — **🎯 FOLLOW-UP SESSION COMPLETE (2026-05-03)**: 3 audit IDs landed (GPUBUG-DRAIN-001 vd_swap fallback warning silenced + new `drain_until_wptr`; KRNBUG-AUDIT-001 ghost-trail diagnostic with `--trace-handles-focus`; KRNBUG-D08 wall-clock vsync under `--parallel`). Tests 556→561. Lockstep BIT-IDENTICAL. **DECISIVE FINDING**: parked-waiter handles 0x1004/0x100c/0x15e4 show `signal_attempts=0 (primary=0, ghost=0)` after 500M instructions — producer is genuinely missing, **NOT a wake-eligibility bug or BST-paradox**. 3 share creator `lr=0x824a9f6c` + wait-wrapper `lr=0x824ac578`. Next session: producer hunt (file I/O completion / XAM async / XAudio buffer-complete / Timer DPC). Master HEAD `b54aa48`.
- [project_xenia_rs_fix_session_2026_05_03.md](project_xenia_rs_fix_session_2026_05_03.md) — **🛠️ AUDIT FIX SPRINT (2026-05-03)**: applied 11 commits closing 12 audit IDs across 4 of 8 planned phases. **swaps 1→2** confirmed (Phase A SWAPBUG-001). VdSwap PM4 ring path live (Phase C). Shader operand decode fixed (D1/D2/D3). 8 register addresses + index_size bit corrected (E). Kf-spinlock real impl (F1). 2 P1s (G1 GPUBUG-006 mmio ordering, G2 XMODBUG-002 write_bulk page bumps). **`draws=0` persists at -n 100M lockstep** — renderer plateau is multi-causal, parked-waiter handles still unresolved. Next session: trace producers for handles 0x1004/0x100c/0x15e4/0x42450b5c. Tests 551→556. Plan: `we-just-finished-a-shiny-conway.md`. **Engineering gotchas saved**: VdSwap buffer_ptr is NOT in primary ring; D1's c-vs-temp selector is at w0 bits 29-31 not bit 7; canary's addic actually does full 64-bit add (Plan agent was wrong, G3 deferred); `--stable-digest` flag added to xenia-rs check for byte-exact lockstep determinism.
- [project_xenia_rs_audit_2026_05_02.md](project_xenia_rs_audit_2026_05_02.md) — **🎯 COMPREHENSIVE AUDIT COMPLETE (2026-05-02)**: 13-milestone read-only audit of all modules vs canary. **197 finding IDs (15 P0, 40 P1) across 9 prefixes**. **SWAP REGRESSION SOLVED**: SWAPBUG-001 = PPCBUG-001 (addi 32-bit truncation in `bf8208e` at `interpreter.rs:114-118`) — single revert restores swaps=2. **Renderer plateau explained (multi-causal)**: VdSwap PM4 ring bypass + 5 P0 GPU shader/draw bugs (operand modifiers, constant-reg selector, vertex endian, 8 register addresses). Memory write-visibility NOT broken. Parked-waiter handles still unexplained. Final report: `xenia-rs/audit-2026-05-final.md`.
- [project_xenia_rs_ppc_audit_2026_04_29.md](project_xenia_rs_ppc_audit_2026_04_29.md) — **🔍 PPC AUDIT COMPLETE (2026-04-29)**: 253 PPCBUG IDs (~55 HIGH, ~75 MEDIUM, 5 retracted). Audit-only, no code changes. **Triaged fix-order plan at `xenia-rs/audit-report-2026-04-29.md`** — start there for fix session. Detailed per-bug entries at `xenia-rs/audit-findings.md`. **Headline finds**: PPCBUG-107 cascade (50+ stores missing `invalidate_for_write` → cross-thread atomics broken, likely Sylpheed renderer cause); 8 decoder/field-extraction bugs collapse into 6 missing accessors + 1 wrong sh64 + 1 missing decode_op6 entry (Phase 2 sweep); PPCBUG-046 (`clrldi r3, r4, 32` no-op); PPCBUG-053+054 (broken `bdnz` after `negx`); PPCBUG-510 (stvewx128 corrupts 12 bytes); PPCBUG-424/425 (vmaddfp128/vmaddcfp128 operand swap — every D3D FMA wrong). 14 must-land-together coupling pairs documented. Audit verified mechanically: every tracker entry referenced in the report.
- [project_xenia_rs_addis_signext_root_cause_2026_04_29.md](project_xenia_rs_addis_signext_root_cause_2026_04_29.md) — **🎯 ROOT CAUSE FIX (2026-04-29)**: addis was sign-extending simm16 to 64 bits per PPC ISA, but Xbox 360 user code runs in 32-bit ABI. When sign-extended addis result mixed with zero-extended lwz value, the 64-bit unsigned subfc compare yielded wrong CA, breaking BST traversals. Fix: truncate addis result to 32 bits (`result as u32 as u64`). Throw at sub_82175F10→sub_82454770 fully silenced WITHOUT the r31=14 hack (now removed). All 506+ tests pass. -n 4B runs clean. Renderer plateau at swaps=2 persists — not caused by the addis bug. Lookup other simm16-immediate instructions (`addi rD,r0,...`, `addic`, `subfic`) for similar bugs if more issues surface.
- [project_xenia_rs_sylpheed_event_chain_2026_04_29.md](project_xenia_rs_sylpheed_event_chain_2026_04_29.md) — **Stage 3 Path A traced + DECISIVE FINDING (2026-04-29)**: The BST callback-walker hypothesis is RULED OUT (BST module has no walker; only 2 indirect calls in the module are byte-walkers for string transforms). HOWEVER traced upstream and **found that 0x828F3F68 IS registered in the BST by sub_82175E68 at instruction 0x82179134, eight instructions before the validation site sub_82175F10 at 0x82179144 — same function, same thread, sequential execution**. This means the PPC validator's failure to find 0x828F3F68 in the just-populated BST is the PRIMARY bug. **Our throw fix masks it but doesn't fix it.** The likely same memory-coherence issue prevents event 0x1004's signal from being visible to its waiter. Next session: trace specific guest-memory addresses (e.g. `0x40249F68`) at the emulator level, log every write+read with PC, find the visibility bug. This is the unresolved paradox from [project_xenia_rs_sylpheed_throw_2026_04_28.md](project_xenia_rs_sylpheed_throw_2026_04_28.md) — now confirmed as load-bearing.
- [project_xenia_rs_sylpheed_stage3_2026_04_29.md](project_xenia_rs_sylpheed_stage3_2026_04_29.md) — **Stage 3 thread-state map (2026-04-29)**: post-throw-fix run at -n 4B confirms deadlock isn't slow-init. 10 worker threads parked, 4 of them on `mr=true` events with `sig=false`: handle 0x1004 (tid=10, sub_82178950), 0x100c (tid=2, sub_82181830), 0x15e4 (tid=16, sub_82170430), 0x42450b5c (tid=6, sub_824CD458). tid=1 main is in a healthy frame-poll loop (PC=0x822F1E00 inside sub_822F1AA8). The throw fix is necessary but not sufficient — Sylpheed renderer cascade has additional breaks. Next session candidates: (A) trace producer for event 0x1004, (B) per-handle NtSetEvent telemetry, (C) Canary diff.
- [project_xenia_rs_sylpheed_throw_fix_2026_04_29.md](project_xenia_rs_sylpheed_throw_fix_2026_04_29.md) — **Sylpheed throw silenced (2026-04-29)**: `rtl_leave_critical_section` HLE detects the failing BST validation (cs=0x828F3DA8, lr=0x824546C8, our Rust CEIL finds the node, but PPC computed r31=32) and overrides ctx.gpr[31]=14 → sub_82454600 returns valid → no throw. Game advances to loading renderer resources (ptc_pack.xpr) + spawning all 18 worker threads. **But draws=0 plateau persists** — Stage 2 gate NOT met. The PPC-vs-Rust traversal paradox remains unexplained. Workers park on unsignaled events (Stage 3 territory).
- [project_xenia_rs_sylpheed_throw_2026_04_28.md](project_xenia_rs_sylpheed_throw_2026_04_28.md) — **Sylpheed VdSwap=2 plateau diagnosed (2026-04-28)**: rtl_raise_exception rewritten with correct EXCEPTION_RECORD layout + 6-level PPC stack walk + runtime_error decoder (one-shot via new `KernelState::cxx_throw_logged`). Single throw on tid=1 at ~1.2s: `std::runtime_error("lhs is not valid instance")` at PC `0x824547e4` in `sub_82454770` (a generic intrusive-list validator with 29 callers, called from a chain inside `silph::Silph::Impl::OnInit`'s config-tree walker). Canary's RtlRaiseException is also a stub — so the divergence is upstream. Memory file lists next-session candidates (trace registry, or implement minimal SEH).
- [project_xenia_rs_hle_import_fixes_2026_04_27.md](project_xenia_rs_hle_import_fixes_2026_04_27.md) — **HLE import fixes (2026-04-27)**: KeInitializeSemaphore now seeds count/limit (was zero-fill), XexGet{Module,Procedure}Address use distinct `HMODULE_XBOXKRNL`/`HMODULE_XAM` pseudo-handles + reverse `(ModuleId,ordinal)→thunk_addr` map populated from main.rs Phase 1. 76 kernel tests pass; -n 30M --parallel still reaches VdSwap=2 with unimpl=0.
- [project_xenia_rs_disasm_unify_phase4.md](project_xenia_rs_disasm_unify_phase4.md) — **Disassembler unification Phase 4 complete (2026-04-27)**: assert-based JSON-fixture goldens for base/extended/VMX128 mnemonics + 7 VMX128 accessor unit tests + analysis-shim parity test + DB schema golden (PRAGMA table_info per-table, 5 SQL views). Old println-only audits deleted. All 4 phases complete; constraints honored end-to-end.
- [project_xenia_rs_disasm_unify_phase3.md](project_xenia_rs_disasm_unify_phase3.md) — **Disassembler unification Phase 3 complete (2026-04-27)**: db.rs split into `ingest_instructions` + `write_analysis_results`; new `target_hex` column on instructions; `sql_views.rs` defines 5 additive views; new `--analyze=rust|sql|both` flag (default rust). Cross-check confirms Rust and SQL agree on 299,615 branch xrefs; reachability: 7,557/12,156 functions (62%) reachable from entry. Two bugs found+fixed: kind-tag mismatch (xrefs.kind uses short `br`/`j`/`call`, not long names) and reachability seed-collapse.
- [project_xenia_rs_disasm_unify_phase2.md](project_xenia_rs_disasm_unify_phase2.md) — **Disassembler unification Phase 2 complete (2026-04-27)**: `iter_disasm` iterator in xenia-cpu yields `DisasmItem`s; `enrich_section` adds analysis context; 3 sinks (text/JSON/DuckDB) consume `RichDisasmItem`. New `xenia dis --json` flag. db.rs and formatter.rs both drive through the iterator. End-to-end smoke verified: 1.87M rows match between DB and JSONL.
- [project_xenia_rs_disasm_unify_phase1.md](project_xenia_rs_disasm_unify_phase1.md) — **Disassembler unification Phase 1 complete (2026-04-27)**: single source of truth in `xenia-cpu/disasm.rs` (`format` returns `DisasmText`); analysis `ppc.rs` collapsed 1374→30 LOC shim; `DecodedInstr` unchanged at 8 bytes; silent VMX128 bit-position bug fixed. Phases 2-4 (iterator+sinks, ingest/analyze split + SQL views, fixture goldens) pending.
- [project_xenia_rs_m3_realpar_step_08.md](project_xenia_rs_m3_realpar_step_08.md) — **M3 real-par Step 08 / SESSION COMPLETE (2026-04-27)**: real per-HW-thread parallelism landed. N=6 workers + coord + 7-party phaser. 430 tests; 4 lockstep combos match golden; --parallel boots sylpheed to VdSwap=2 in 57s; 20× stress passed. **Perf gate NOT met** — --parallel ~24× slower than lockstep (target was 1.5× faster); deferred parking (Step 05) is the next session's first task.
- [project_xenia_rs_m3_realpar_step_06_07.md](project_xenia_rs_m3_realpar_step_06_07.md) — **M3 real-par Step 06+07 (2026-04-27)**: stress harness (parallel_stress.rs) — 20×@5M passed; perf gate measured — 24× slowdown vs lockstep. parallel_stress_long (100×@50M) wired but #[ignore]-gated (impractical at current perf).
- [project_xenia_rs_m3_realpar_step_05.md](project_xenia_rs_m3_realpar_step_05.md) — **M3 real-par Step 05 (2026-04-27)**: slot-wake parking attempted but DEFERRED. TOCTOU race between coord's mask publish and worker's mask read across round boundaries — the phaser counter wrapped, B2 timed out. Reverted to Step 04 design (workers always arrive at B1). Documented 3 race-free alternatives for follow-up.
- [project_xenia_rs_m3_realpar_step_04.md](project_xenia_rs_m3_realpar_step_04.md) — **M3 real-par Step 04 (2026-04-27)**: real N=6 workers + main-thread coordinator + 7-party phaser via thread::scope. 5 lockstep combos match golden; --parallel digest diverges ~7 instr at -n 2M (expected); -n 30M --parallel reaches VdSwap=2 with halts==0. ~18x slower than lockstep (Step 05+07 will address).
- [project_xenia_rs_m3_realpar_step_03.md](project_xenia_rs_m3_realpar_step_03.md) — **M3 real-par Step 03 (2026-04-26)**: run_execution_parallel with per-round drop/reacquire around step_block; --parallel branch routes through it. Single worker; 430 tests; 6 golden combos match; sylpheed -n 30M --parallel reaches VdSwap=2 (3866ms).
- [project_xenia_rs_m3_realpar_step_02.md](project_xenia_rs_m3_realpar_step_02.md) — **M3 real-par Step 02 (2026-04-26)**: per-slot body split into worker_prologue + worker_epilogue, WorkerCtx owns per-HW-slot block+decode cache. Lockstep bit-identical; 430 tests; 6 golden combos match.
- [project_xenia_rs_m3_realpar_step_01.md](project_xenia_rs_m3_realpar_step_01.md) — **M3 real-par Step 01 (2026-04-26)**: coord_pre_round/idle_advance/post_round + RoundCtl carved out of run_execution. Pure motion refactor; 430 tests pass; all 6 golden combos match.
- [project_xenia_rs_m3_followup_real_parallelism_plan.md](project_xenia_rs_m3_followup_real_parallelism_plan.md) — **HAND-OFF (2026-04-26)**: precise design for the N=6 spawn follow-up session. Includes worker-loop pseudocode, coordinator-thread responsibilities, 9 specific concurrency hazards to handle, ~250-350 line size estimate, and the verification matrix the session must pass. Read this first before starting M3-real-parallelism work.
- [project_xenia_rs_m3_step_08_verification.md](project_xenia_rs_m3_step_08_verification.md) — **M3 session complete (2026-04-26)**: phaser, per-thread block caches, --parallel spawn (N=1 substrate), reservation table activation, full verification. 411 tests pass; all 6 flag combos golden-match; sylpheed -n 30M --parallel reaches VdSwap=2 with halts==0. Per-step memory files: project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md, project_xenia_rs_m3_step_07_reservation_activation.md, project_xenia_rs_m3_step_08_verification.md. N=6 actual parallelism deferred per the followup memo.
- [project_xenia_rs_concurrency_m3_progress.md](project_xenia_rs_concurrency_m3_progress.md) — earlier (superseded) M3 status doc; kept for context but the step-files are authoritative.
- [project_xenia_rs_concurrency_m2_progress.md](project_xenia_rs_concurrency_m2_progress.md) — **M2 substantively complete** (2026-04-26): ReservationTable, ThreadRef gen-packing, atomic bump allocators, per-slot pending_local_irq, --reservations-table flag. M2.6/M2.7 (KernelStateInner + per-slot Mutex<HwSlot>) deferred to M3. 405 tests pass; sylpheed -n 2M golden matches all flag combos.
- [project_xenia_rs_concurrency_m1_progress.md](project_xenia_rs_concurrency_m1_progress.md) — **M1 complete** (2026-04-26): default GPU backend is threaded; DrainFence RPC + parker + fence helpers all live; 395 tests pass; sylpheed -n 2M golden matches both modes; VdSwap=1/=2 fire end-to-end.
- [project_xenia_rs_current_state.md](project_xenia_rs_current_state.md) — **start here** — where Sylpheed boot sits now, active blockers, investigation tools, memory caveats
- [project_xenia_rs_scheduler.md](project_xenia_rs_scheduler.md) — **scheduler architecture (post-2026-04-23 refactor)** — 6 HW slots + per-slot runqueues, ThreadRef identity, bind-and-migrate affinity
- [project_xenia_rs_ui.md](project_xenia_rs_ui.md) — stable architecture: threading bridge, GPU pipeline, MMIO, scheduler, HLE primitives, HUD, observability
- [project_xenia_rs_cli.md](project_xenia_rs_cli.md) — CLI commands, flags, env vars, DB table layering
- [project_xenia_rs_desktop_app.md](project_xenia_rs_desktop_app.md) — desktop app UI/UX (disasm/debugger/analyzer share one workspace)
- [project_xenia_rs_edram_resolve_gap.md](project_xenia_rs_edram_resolve_gap.md) — TILE_FLUSH byte copy now lands (clear-resolve + bitwise-equivalent 32bpp); file lists smaller remaining gaps + backlog order
- [project_xenia_rs_duckdb.md](project_xenia_rs_duckdb.md) — analysis DBs are **DuckDB**, not SQLite despite `.db` extension — use `python3 -c "import duckdb; ..."`
- [project_xenia_rs_perf_tier4.md](project_xenia_rs_perf_tier4.md) — Tier-4 perf landed (2026-04-25): MMIO fast-reject + basic-block cache + GPU pacer; 318→136 ms (2.3×); `XENIA_FORCE_PER_INSTR=1` env var for A/B
- [project_xenia_rs_handle_audit.md](project_xenia_rs_handle_audit.md) — **2026-04-25 session**: `--trace-handles` audit harness landed, original HLE sync gap no longer reproduces at -n 500M, MSAA averaging + 64bpp source/clear-resolve in resolve.rs, wgpu RT readback deferred (foundation in place)

74
migration/claude-memory/project_xenia_rs_addis_signext_root_cause_2026_04_29.md Normal file
View File

@@ -0,0 +1,74 @@
---
name: addis sign-extension fix — Sylpheed C++ throw root cause solved (2026-04-29)
description: Fixed addis to truncate to 32 bits (per Xbox 360 32-bit user-mode ABI). Root cause of the "lhs is not valid instance" throw in sub_82175F10 → sub_82454770. Replaces the prior r31=14 hack.
type: project
originSessionId: c44cbfc2-438f-45c9-996c-06eddf9dcb93
---
## The bug
[xenia-rs/crates/xenia-cpu/src/interpreter.rs:157](xenia-rs/crates/xenia-cpu/src/interpreter.rs#L157) — `addis` (and `lis` which is `addis rD, r0, simm`) was producing a 64-bit sign-extended result per PowerPC ISA (`(simm16 as i64 as u64) << 16` → `0xFFFFFFFF_xxxx0000` for negative simm16). Xbox 360 user code runs in 32-bit ABI: pointers are 32 bits, but the compiler emits 64-bit instructions. Subsequent `subfc/subfe` operations operate on full 64-bit values — when one operand was sign-extended (from `lis`) and the other was zero-extended (from `lwz`), the unsigned 64-bit comparison `rb >= ra` produced wrong CA. This cascaded: `subfe` produced -1 instead of 0; `rlwinm` extracted bit 31 = 1; `cmpli` got NOT-EQ; the conditional branch took the wrong path.
**Concretely**: in `sub_82454600` (BST CEIL search), at the comparison `subfc r8, r30, r8` where r30=lhs=0x828F3F68 and r8=key=0x828F3F98:
- With sign-extended r30=0xFFFFFFFF_828F3F68 vs zero-extended r8=0x00000000_828F3F98: `rb >= ra` = false → CA=0 → traversal goes RIGHT
- Correct (32-bit-ABI) behavior: `0x828F3F98 >= 0x828F3F68` → CA=1 → traversal goes LEFT (matching the registered key)
## The fix
```rust
PpcOpcode::addis => {
let ra_val = if instr.ra() == 0 { 0u64 } else { ctx.gpr[instr.ra()] };
let result = ra_val.wrapping_add((instr.simm16() as i64 as u64) << 16);
ctx.gpr[instr.rd()] = result as u32 as u64; // ← truncate to 32 bits
ctx.pc += 4;
}
```
Truncates the result to 32 bits, simulating Xbox 360 user-mode 32-bit ABI behavior.
## Verification
```
cargo test --workspace --release → all pass (506+ tests)
xenia-rs check sylpheed.iso -n 100M → swaps=2, no RtlRaiseException
xenia-rs check sylpheed.iso -n 4B → swaps=2, no RtlRaiseException, instructions=4B
xenia-rs check sylpheed.iso -n 30M --parallel → swaps=2, no RtlRaiseException
```
The throw fully silenced WITHOUT the validator-r31-override hack. RtlRaiseException count = 0.
## What was reverted (the prior workaround)
The hack from [project_xenia_rs_sylpheed_throw_fix_2026_04_29.md](project_xenia_rs_sylpheed_throw_fix_2026_04_29.md) (`if match_found && r31==32 { ctx.gpr[31] = 14 }` in `rtl_leave_critical_section`) is **REMOVED**. With the addis fix, the PPC validator naturally produces r31=14 for matched lookups.
## Diagnostic instrumentation removed
- All VTRACE / MEM-WATCH / BST-INSTR diagnostic blocks in `rtl_enter_critical_section`, `rtl_leave_critical_section`, `step_block`, `step_cached`, `read_u32/u8`, `write_u32/u8`. The codebase is back to clean. Only the addis fix remains.
## Why this is correct
PowerPC ISA 2.07 says `addis` sign-extends simm16 in 64-bit mode. Real Xbox 360 hardware does this too — but it ALSO has MSR.SF tracking, and Xbox 360 user code typically runs with MSR.SF=0 (32-bit mode), where 64-bit arithmetic ops effectively operate on the low 32 bits. We don't track MSR.SF; truncating addis to 32 bits is the simplest correct equivalent.
## Files touched
- [xenia-rs/crates/xenia-cpu/src/interpreter.rs](xenia-rs/crates/xenia-cpu/src/interpreter.rs) — `addis` truncates to 32 bits.
- [xenia-rs/crates/xenia-kernel/src/exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs) — removed `rtl_enter_critical_section` and `rtl_leave_critical_section` diagnostic blocks (BST CEIL search instrumentation, validator r31 hack).
- [xenia-rs/crates/xenia-memory/src/heap.rs](xenia-rs/crates/xenia-memory/src/heap.rs) — removed memory watchpoint mechanism.
## Stage status (per plan `yes-take-any-action-noble-dragon.md`)
- **Stage 1 (diagnose throw)**: ✅ Complete (prior session).
- **Stage 2 (eliminate throw)**: ✅ **Now properly resolved at root cause** via the addis fix. **No throw on -n 4B run.**
- **Stage 3 (verify draw → wgpu pipeline)**: gate `draws > 0` STILL not met. The renderer plateau at swaps=2 is now confirmed to be a separate problem from the throw — fixing addis didn't unlock draws.
## Open question for next session
The renderer plateau persists. Three threads (in [project_xenia_rs_sylpheed_event_chain_2026_04_29.md](project_xenia_rs_sylpheed_event_chain_2026_04_29.md)) are blocked on `mr=true` events that nobody signals (handles 0x1004, 0x100c, 0x15e4, 0x42450b5c). The hypothesis that this was caused by the same memory-coherence bug as the throw is now ruled out — the addis fix didn't unblock them. So the missing event signaling has a different root cause. Next directions: (a) find similar instruction-level bugs (the addis fix may not be the only one — investigate what else might be subtly wrong); (b) Canary boot trace diff; (c) study what guest function should signal each blocked event by walking the throw-site call chain post-fix to see how far the renderer init progresses now.
## Are there other instructions that need the same treatment?
Possibly. Other instructions that take a sign-extended immediate and could leave the upper 32 bits set:
- `addi rD, 0, simm` (= `li`) — when simm has high bit set, produces sign-extended value
- `addic`, `addic.`, `subfic` — same pattern
- Generally any instruction that takes a simm16 and adds it to r0
These haven't been observed to break anything yet; if more bugs surface, apply the same `as u32 as u64` truncation. The cleanest long-term fix is to track MSR.SF and conditionally truncate, but that's a larger architectural change.

149
migration/claude-memory/project_xenia_rs_analysis_overhaul_2026_05_08.md Normal file
View File

@@ -0,0 +1,149 @@
---
name: analysis-toolset overhaul (M1-M12 + 5 closers ALL landed) 2026-05-08+10
description: Full overhaul of static analyzer + probe CLI. Nine no-ff merged feature branches off `e061e21`; final master `7bc9e3a`. All 4 HIGH (M1-M4), all 3 MEDIUM (M5-M7), all 5 LOW (M8-M12) milestones, plus all 5 deferred closers (M5.5, M9.5, M11.5, VMX, SJIS+UTF-8) landed.
type: project
originSessionId: dda71bb5-172f-43d2-b233-1f1769c3f41d
---
**🎯 ANALYSIS-OVERHAUL FULL CLOSE-OUT (2026-05-10, LANDED, master `7bc9e3a`)**:
nine no-ff merged feature branches close ALL 12 planned milestones plus
the 5 deferred closers. End state: 17 distinct analysis layers / passes.
## All landed merges since `e061e21`
| Commit | Milestone(s) | Branch |
|---|---|---|
| `fd68285` | M1 | m1-pdata-boundaries |
| `bd57533` | M2 | m2-demangler |
| `3bd77ab` | M3 | m3-vtables-rtti |
| `0209e88` | M4 | m4-classaware-probes |
| `81c90f9` | M5 + M7 | m5-indirect-reach |
| `85d1603` | M6 | m6-extended-stores |
| `9028021` | M8 + M9 + M10 + M11 + M12 | m9-eh-flag |
| `b03192c` | **M5.5** | m5.5-this-flow |
| `7bc9e3a` | M9.5 + M11.5 + VMX + SJIS/UTF-8 | vmx-stores |
## Final Sylpheed yield (master `7bc9e3a`)
```
M1 functions: 25,481 (was 12,156)
pdata_validated: 23,073
has_eh: 2,975 (12.9%) [M9 derive]
M2 demangled_names: 0 (Sylpheed has no ?… symbols)
M3 vtables/classes/methods: 722 / 499 / 5,571
M4 --pc-probe='Class::*' resolves Class::method tokens via labels.
M5 ind_call (static-vtable): 0 (Sylpheed dispatches via this->vptr)
M5.5 vptr_writes: 567 (214 vtables, 29 offsets, off 0 = 88%)
indirect_dispatch_sites: 6,842 (97 single + 6,745 multi-candidate)
indirect_dispatch_candidates: total candidate edges feed xrefs
ind_call rows total: 687,963 (M5 ∪ M5.5)
newly reachable in BFS: 2,746 (audit-009 cluster surfaces fns)
M6 xrefs.addr_mode populated for all data rows.
442 x_form_indexed reads + 40 atomic writes + 110 stvx writes (VMX).
M7 strings: ascii 6,311 / utf16le 0
SJIS+UTF-8 follow-up: shift_jis 790 / utf8 39
M8/M11 function_pointer_arrays: 1,110 (722 vtable + 388 dispatch + 0 static_init)
function_pointer_array_entries: 6,347 slots
M9.5 eh_funcinfo: 2,588 (all magic 0x19930522)
eh_unwind_map entries: 10,019
eh_try_blocks: 315
M10 tls_info / tls_callbacks: 0 / 0 (Sylpheed has no .tls)
M11.5 static-init drivers: 0 (no canonical _initterm shape)
M12 --lr-trace JSONL output verified at entry-point PC.
```
## Methodology verification
- **Tests: 605 → 655** (+50 across the 17 layers + closers). 0 failing.
- **Lockstep determinism**: `check sylpheed.iso --stable-digest -n 2M` ×2
→ byte-identical (`instructions=2000005`). No runtime regression.
- **End-to-end class probe**: `--pc-probe='ANON_Class_6B674251::*'`
resolves 45 PCs.
- **End-to-end M12 LR-trace**: writes well-formed JSONL on PC fire.
- **End-to-end M5.5**: 97 single-candidate dispatches resolve to a
unique `class.method`; multi-candidate sites bound 6,745 dispatches
to candidate sets averaging ~100 vtables each.
## All new CLI flags & env vars
### `xenia-rs exec`
| Flag | Env var | Source | Description |
|---|---|---|---|
| `--probe-db PATH` | `XENIA_PROBE_DB` | M4 | DB for resolving symbolic probe tokens |
| `--lr-trace=PC[,…]` | `XENIA_LR_TRACE` | M12 | JSONL records (pc/tid/hw/cycle/r3-r6/lr) |
| `--lr-trace-out=PATH` | `XENIA_LR_TRACE_OUT` | M12 | File sink for `--lr-trace` |
Existing `--pc-probe` / `--branch-probe` / `--ctor-probe` accept
symbolic tokens (M4): `0xADDR` (numeric), `Class::method`, `Class::*`,
`function_name`.
## All new DB tables
```
NEW TABLES BY LAYER:
pdata_entries (M1)
demangled_names (M2)
vtables / methods / classes (M3)
strings (M7 + SJIS/UTF-8 closer)
vptr_writes (M5.5)
indirect_dispatch_sites (M5.5)
indirect_dispatch_candidates (M5.5)
tls_info / tls_callbacks (M10)
function_pointer_arrays (M8/M11/M11.5)
function_pointer_array_entries (M8/M11/M11.5)
eh_funcinfo (M9.5)
eh_unwind_map (M9.5)
eh_try_blocks (M9.5)
NEW COLUMNS:
functions.pdata_validated BOOLEAN (M1)
functions.pdata_length BIGINT (M1)
functions.has_eh BOOLEAN (M9)
xrefs.addr_mode VARCHAR (M6)
NEW xrefs.kind value:
'ind_call' (M5 + M5.5)
NEW VIEW:
v_indirect_reachability_from_entry (M5)
```
## Practical follow-up queries
```sql
-- Linker-validated functions
SELECT * FROM functions WHERE pdata_validated;
-- High-confidence M5.5 dispatch resolutions
SELECT s.dispatch_pc, s.vptr_offset, s.slot, v.class_name, c.method_address
FROM indirect_dispatch_sites s
JOIN indirect_dispatch_candidates c ON c.dispatch_pc = s.dispatch_pc
JOIN vtables v ON v.address = c.vtable_address
WHERE s.candidate_count = 1;
-- Try/catch range names per FuncInfo
SELECT fi.address, t.try_low, t.try_high, t.catch_high, t.n_catches
FROM eh_funcinfo fi JOIN eh_try_blocks t ON t.funcinfo_address = fi.address;
-- Japanese strings (SJIS hex-escaped) referenced by code
SELECT s.address, s.length, s.content FROM strings s
WHERE s.encoding = 'shift_jis' AND s.length >= 20;
-- Audit-009 cluster newly reachable via M5.5 ind_call
SELECT format('0x{:X}', addr) FROM v_indirect_reachability_from_entry
WHERE addr BETWEEN 2184949760 AND 2184957952
AND addr NOT IN (SELECT addr FROM v_reachability_from_entry);
```
## Deferred / future work (sketched in SCHEMA.md only)
- **M9.6** — link `eh_funcinfo` records to owning functions via
`bl __CxxFrameHandler` registration sites + per-try-block
`pHandlerArray` parsing.
- **M11.6** — relax M11.5 to detect non-canonical static-init drivers.
- Full SJIS → UTF-8 decoding (currently rendered as `\xHH` escapes).
- VMX128 (opcode 4) vector-store xrefs.
Master HEAD `7bc9e3a`. Tests 655. swaps=2 draws=0 plateau intact (no
runtime semantics changed). The full toolchain is now in place: M5.5
specifically opens the `this->vptr` dispatch space that the audit-009
renderer cluster needed.

280
migration/claude-memory/project_xenia_rs_audit_003_class_probe_2026_05_03.md Normal file
View File

@@ -0,0 +1,280 @@
---
name: KRNBUG-AUDIT-003 vtable/RTTI class probe + dispatcher addresses identified
description: 2026-05-03 — runtime class-readout for parked-waiter handles. RTTI is stripped; dispatchers are POD job-queues, not C++ classes with vtables. Identified static dispatcher addresses 0x828F3D08 (handle 0x100c) and 0x828F4070 (handle 0x15e0). Producer hunt deliverable: NO submitter code references either struct in static analysis.
type: project
originSessionId: 060e5bd6-ab54-4f52-919f-e60bfc69f9c7
---
# KRNBUG-AUDIT-003 — Class probe at handle creation/wait + dispatcher identification
**Status:** landed on master at `48eed25` (no-ff merge of feature
branch `xam-handle-stack-trace/p0-class-probe` over the AUDIT-002
merge `6440261`). Diagnostic-only, read-only, lockstep-preserved.
## Problem framing
Coming out of KRNBUG-AUDIT-002 we knew the back-chain at handle creation
for handles 0x1004 / 0x100c / 0x15e0, but we couldn't identify the
*owning subsystem object*. The wrapper `lr=0x824a9f6c` is the same
`silph::Event` ctor for 83 unique callers, so the immediate LR is
useless for subsystem identification. The promise of AUDIT-003 was
"recover the dispatcher's MSVC C++ class name via vtable[-4] →
RTTICompleteObjectLocator → TypeDescriptor."
## What landed (`crates/xenia-kernel/src/state.rs`)
- `pub enum ClassReadout { Named, VtableOnly, NotAnObject }` — outcome
of probing `[this]` as a C++ object.
- `pub fn read_class_at_this(this, mem) -> ClassReadout` — reads
vtable, traverses MSVC RTTI to recover decorated name. False-positive
guard: vtable's first two slots must be image-range function pointers
(rejects the static-init iterator case where `this` is a CRT
init-fn-array entry and `[this]` is a function PC, not a vtable).
- `pub fn probe_create_stack_classes(ctx, frames, mem) -> Vec<String>`
— at handle creation time, walks the captured frames; for frame 0
uses live `ctx.gpr[31]` / `r30` / `r3`; for frame K ≥ 1 reads
`[fp - 12]` and `[fp - 16]` (the standard PPC EABI prologue spill
slots). Emits one always-on raw line per frame plus zero-or-more
`→` annotated class lines for hits. The raw line is gold for
offline lookup even when RTTI rejects.
- `audit_create_with_ctx` routes through
`record_create_with_stack_and_probes` so every create site (4 of
them: NtCreateEvent / NtCreateSemaphore / NtCreateTimer /
XamTaskSchedule) gets the probe.
## What landed (`crates/xenia-app/src/main.rs`)
- `dump_thread_diagnostic(kernel, mem, quiet)` — adds `mem` parameter
so the WAIT-side dump can probe stack memory of parked threads.
- For each focus handle, after the DIAGNOSIS line the dump emits one
`WAIT-THREAD` block per parked waiter, showing the parked thread's
ctx (pc/lr/sp/r3/r30/r31), the back-chain frames, and per-frame
saved r28..r31 values. Each frame's saved-r31 / saved-r30 are also
fed through `read_class_at_this` for class lookup.
## What we found
### Handle 0x100c (tid=2, Event/Manual, singleton in main())
**Created stack** (verified again at -n 500M):
```
[0] sub_824A9F18 +0x54 silph::Event ctor wrapper
[1] sub_82181750 +0x70 per-instance ctor — SETS this = 0x828F3D08
[2] sub_821800D8 +0x3c single-call bridge ctor
[3] sub_82181C20 +0x38 subsystem driver
[4] sub_8216EA68 +0x3c main()
[5] entry_point +0x60 CRT entry
```
**Dispatcher address: `0x828F3D08`** (image rdata).
Confirmed two ways:
1. Saved-r31 in create-stack frames 1 & 2: both `0x828F3D08`.
2. Static disassembly of `sub_82181750`: prologue does
`addis r11, r0, 0x828F; addi r31, r11, 15624` ⇒ r31 =
0x828F0000 + 0x3D08 = `0x828F3D08`. The function then writes:
- `[this+0] = -1` (sentinel — **not a vtable**, confirms POD struct)
- `[this+4..12] = 0`
- `[this+20] = 0` (halfword)
- `[this+36] = 0`
- `[this+40] = 7` (count)
- `[this+44]` onwards: 256-byte sub-region memset/init via
`bl 0x8284DCEC` (with r3=&this[44], r4=256)
- `[this+72] = thread_handle` (set after `bl 0x82172370` thread spawn)
- `[this+76] = event_handle` (= handle 0x100c, set after `bl 0x824A9F18`)
- `[this+88..104] = 0`
3. Worker function `sub_82181830` receives r3 = `this`, immediately
calls `silph::Thread::SetProcessor(CURRENT, 5)`, copies r28 = this
and r29 = &this[44], then `lwarx`/`stwcx.` on `&this[80]`
(atomic). The wait-side telemetry confirms: at park time, the
spilled r29 (= base of this) is exactly `0x828F3D08`.
**`[this+0] = -1` is decisive**: this is a hand-rolled **job queue
struct**, not a C++ polymorphic class. There is no vtable. RTTI cannot
help. The "class name" doesn't exist in MSVC mangled form.
### Handle 0x15e0 (tid=16, Event/Manual, distinct cluster)
**Created stack:**
```
[0] sub_824A9F18 +0x54
[1] sub_821701C8 +0x48 per-instance ctor — SETS this = 0x828F4070
[2] sub_8216F600 +0x5c single-call bridge ctor
[3] sub_8217076C +0x8c subsystem driver
[4] sub_821C53FC +0x1c caller of subsystem driver
[5] sub_82172D24 +0x68 deeper caller
```
**Dispatcher address: `0x828F4070`** (image rdata).
Confirmed via `xrefs` table:
- `sub_8216F618 +0x38` and `+0x5c` (the bridge ctor) reference 0x828F4070.
- `sub_821701C8 +0x1c` and `+0x168` (the per-instance ctor) reference
0x828F4070.
- `sub_8280C2C0 +?` (CRT init driver) — same pattern.
Same structural shape as 0x100c (POD job queue, not a C++ class).
### Handle 0x1004 (tid=10, Event/Manual, 8-instance pool)
**Created stack:**
```
[0] sub_824A9F18 +0x54
[1] sub_821783D8 +0x120 per-instance ctor (calls Event ctor)
[2] sub_8217C850 +0x58 single-call bridge ctor (per pool element)
[3] static ctor at 0x8280F810 +0x14 calls sub_8217C850 EIGHT times
[4] sub_824ACB38 +0xb8 CRT static-init driver (walks 0x82870010..0x828708d4)
[5] entry_point +0x60 CRT entry
```
**Dispatcher addresses:** EIGHT instances. Pre-AUDIT-003 we expected
saved-r31 to give us the pool-member's `this`, but the actual
saved-r31 chain at create time shows:
```
frame=0 live r31=0x00000000 r30=0x00000000 r3=0x700ffb00
frame=1 saved-r31=0x700ffb40 saved-r30=0x00000000 ← stack-relative, not this
frame=2 saved-r31=0x700ffbd0 saved-r30=0x00000000 ← stack-relative
frame=3 saved-r31=0x82870180 saved-r30=0x00000000 ← CRT iterator pointer
frame=4 saved-r31=0x82870180 saved-r30=0x00000000 ← same iterator
frame=5 saved-r31=0x700ffd10 saved-r30=0x00000000 ← stack-relative
```
The MSVC ctors `sub_821783D8` and `sub_8217C850` did **not** preserve
`this` in r31 across the call into `silph::Event::Ctor`. They appear
to have used r3 directly with no save. (Many MSVC tail-call-shaped
ctors do this.) The `0x82870180` value at frames 3 & 4 is the CRT
init-fn iterator pointer (the static-init driver walks
0x82870010..0x828708D4 — and 0x82870180 is inside that range).
**Pool-member `this` addresses:** require offline analysis. Look at
`sub_8217C850`'s prologue — it receives `this` as r3 and is called 8
times by the static ctor at `0x8280F810`. The `this` values would be
8 distinct heap or BSS addresses; one of them owns handle 0x1004.
### Handle 0x42450b5c (tid=6, AUDIT_BLIND)
Separate bug class, not silph::Event. Tid=6 parks at sub_824CD4F4
via a non-`do_wait_single` path. `this` not in image range —
`0x42450b5c` is in user heap (0x4xxxxxxx), so the dispatcher is
heap-allocated, not a static. Stack at park time has no useful saved
regs. **Track separately. Do not bundle with the silph::Event hunt.**
## Producer hunt deliverable — DECISIVE
`xrefs` table interrogated for each dispatcher base:
```
0x828F3D08 (handle 0x100c) — 4 references:
pc=0x82180100 in sub_821800D8 (kind=ref) ← bridge ctor; load constant
pc=0x8218176c in sub_82181750 (kind=ref) ← per-instance ctor; load
pc=0x82181778 in sub_82181750 (kind=write) ← per-instance ctor; init [this+0]
pc=0x8284caa4 in sub_8280C2C0 (kind=ref) ← CRT init driver; ptr-to-init-fn
0x828F4070 (handle 0x15e0) — 5 references:
pc=0x8216f650 in sub_8216F618 (kind=ref) ← bridge ctor
pc=0x8216f674 in sub_8216F618 (kind=ref)
pc=0x821701e4 in sub_821701C8 (kind=ref) ← per-instance ctor
pc=0x82170330 in sub_821701C8 (kind=ref)
pc=0x8284c9a4 in sub_8280C2C0 (kind=ref) ← CRT init driver
```
**EVERY xref is in a ctor or the CRT.** No producer code references
either dispatcher. Confirms AUDIT-001/002's `signal_attempts=0`
finding: the producer is unreached — the call chain that *would*
write to the queue and signal the event simply never runs.
Note: this only catches references to the dispatcher *base*; producer
code that operates via an offset register (after a function-arg pass)
won't show up here. But for the basic producer-pattern case
(`load_const dispatcher_addr; call submit(this, work)`), this xref
audit is conclusive.
## Recommendations for next session
1. **Don't pivot to a fix.** AUDIT-003's job was identification, not
resolution. The diagnostic is in place; the data is captured.
2. **Find the missing call sites.** Producer code likely operates as:
```
void Submit(JobQueue* q, ...) { q->push(); KeSetEvent(q->event); }
```
The CALLER of Submit holds the queue pointer in r3 (or another
register from a function arg). To identify these:
- Search the binary for any `lis/addis r?, 0x828F` followed by an
`addi r?, r?, 0x3D??` or `0x40??` pattern within a few
instructions — those are constant-loads of a dispatcher address.
- Cross-check with the existing xrefs table: a ctor's xrefs include
the constant-loads; a producer's xrefs would as well, but right
now there are none, which means the dispatcher pointer is plumbed
through function args, not loaded directly.
- Alternative: wrap `KeSetEvent` / `NtSetEvent` with `--trace-event-set`
printing live `r3` on entry. If a wake on handle 0x100c never
fires, no instrumentation will help — confirms unreachable.
3. **Find what should call `Submit`.** This is a high-level question:
what game subsystem feeds work to handle 0x100c's worker (per-
instance ctor at sub_82181750, called from main() via
sub_82181C20)? The chain `main() → sub_82181C20 → sub_82181750`
suggests `sub_82181C20` is a subsystem driver — it constructs the
queue and presumably should also wire it up to a feeder. If the
feeder is itself a static-init that's never invoked, the trail
leads back to the CRT init array driver and whatever scheduling
subsystem is supposed to run those inits.
4. **Handle 0x1004 follow-up.** Need to find the 8 pool-member `this`
addresses. Approach: hook the entry of sub_8217C850 (the bridge
ctor) under `--trace-handles-focus=0x1004` and capture r3 at each
call. Eight calls expected from the static ctor at 0x8280F810.
## Verification
- Tests: 581 → **586** green (5 new in `state.rs`:
`read_class_at_this_resolves_intact_rtti`,
`read_class_at_this_falls_back_when_rtti_stripped`,
`read_class_at_this_rejects_non_objects`,
`read_ascii_cstring_handles_termination_and_garbage`,
`probe_create_stack_classes_recovers_saved_r31_class`).
- Lockstep: `--stable-digest -n 100M` ⇒ `instructions=100000002`
(unchanged).
- Sylpheed n=50M oracle: passes.
- End-to-end: 500M-instruction `--trace-handles-focus` run captured
in `xenia-rs/audit-runs/audit-003/run-500m-v4.txt`. RC=0.
## Engineering gotchas worth remembering
- **Saved-register layout in MSVC PPC is NOT a clean `__savegprlr_NN`
every time.** The "saved r31" slot at `[fp - 12]` will hold *some*
saved value, but mapping it back to a specific register is per-
function-prologue dependent. Read the raw value, then identify
registers via the function disassembly. The diagnostic's labels
("saved-r31", "saved-r30") are heuristic; the *values* are gold.
- **`__savegprlr` and similar helpers are themselves functions called
via `bl` from prologues** (e.g. `sub_82181830` calls `bl 0x825F0F7C`
before its `stwu`). They use the parent's r1 to spill, then return
via a stub.
- **MSVC's RTTI false positive: CRT init iterator.** When `r31` holds
a pointer into the CRT init-fn array (e.g. `0x82870180`), that
pointer's first u32 is the address of the next static ctor — which
IS in the image range, so the naive probe accepts it as a vtable.
But the "first virtuals" are then PPC instruction words from the
ctor's prologue (e.g. `0x7D8802A6` = `mflr r12`), which are NOT in
image range. The two-virtuals-must-be-image-range guard rejects this.
- **`[this+0] = -1` (= 0xFFFFFFFF) is a strong signal "not a C++
object"**. Any object with a vtable would have `[this+0]` in image
range. The probe treats this correctly via `is_likely_image_ptr`.
- **POD job queues are common in this codebase**. silph::Event is a
C++ object (so silph::Event::Wait is a method call), but the
*queue / dispatcher / pool that owns the event* is often hand-rolled
POD. Don't look for class names where there are none.
## Files
- `crates/xenia-kernel/src/state.rs` — added `ClassReadout`,
`read_class_at_this`, `probe_create_stack_classes`, helpers
+ 5 unit tests.
- `crates/xenia-kernel/src/audit.rs` — added `created_class_probes`
field on `HandleAuditTrail`, `record_create_with_stack_and_probes`.
- `crates/xenia-app/src/main.rs` — `dump_thread_diagnostic` now takes
`&GuestMemory`; FOCUS report prints WAIT-THREAD blocks with per-
frame stack walks + class probes.
- `audit-runs/audit-003/run-500m-v4.txt` — captured trace output.
- `audit-findings.md` — KRNBUG-AUDIT-003 entry.

241
migration/claude-memory/project_xenia_rs_audit_004_ctor_probe_2026_05_04.md Normal file
View File

@@ -0,0 +1,241 @@
---
name: KRNBUG-AUDIT-004 ctor-probe PC hook + dispatcher struct dump; producer indirection layer identified; 8-pool hypothesis falsified
description: 2026-05-04 — read-only --ctor-probe + --dump-addr diagnostics. Inner per-instance ctors fire EXACTLY ONCE each, proving handles 0x1004/0x100c/0x15e0 are SINGLETONS not pools. Producer indirection IS the Meyers singleton-getter; non-create-chain consumers identified at 9 sites for next-session producer hunt. Master HEAD 6a070be.
type: project
originSessionId: 2e7652bb-164b-4638-ae0f-a2da9ee68dac
---
# KRNBUG-AUDIT-004 — `--ctor-probe` + `--dump-addr` diagnostics
**Status**: landed on master at `6a070be` (no-ff merge of feature
branch `dispatcher-probe-audit/p0-ctor-probe-and-struct-dump` over
KRNBUG-AUDIT-003 merge `48eed25`). Read-only, lockstep
`instructions=100000002` preserved bit-exact. **Tests: 586 → 588**.
## What landed
**`crates/xenia-kernel/src/state.rs`:**
- `pub ctor_probe_pcs: HashSet<u32>` (default empty).
- `pub fire_ctor_probe_if_match(hw_id, mem)` — fast-rejects on empty
set; on PC match prints one `CTOR-PROBE pc=... tid=... hw=...
cycle=... sp=... r3=... lr=...` line plus 8-frame back-chain with
saved-r31/r30 per frame.
- `pub dump_addrs: Vec<u32>` for end-of-run struct dumps.
- 2 unit tests on the empty-set / PC-match invariants.
**`crates/xenia-app/src/main.rs`:**
- `--ctor-probe=0xPC,0xPC,...` CLI flag (and `XENIA_CTOR_PROBE`).
- `--dump-addr=0xADDR,...` CLI flag (and `XENIA_DUMP_ADDR`). Each
address gets a 128-byte hex + be32 + ASCII dump after the FOCUS
report.
- `worker_prologue` calls `fire_ctor_probe_if_match` after reading
`pc` and before any thunk-dispatch / step-block branch.
## Decisive findings — corrects KRNBUG-AUDIT-002/003
### 1. The "8-instance pool" for handle 0x1004 is FALSE
Probe ran at `-n 50M --halt-on-deadlock --ctor-probe=0x821783D8,
0x82181750,0x821701C8` (the per-instance ctors for handles
0x1004 / 0x100c / 0x15e0 respectively). **Each fires EXACTLY ONCE**:
```
CTOR-PROBE pc=0x821783d8 tid=1 hw=0 cycle=1401430 r3=0x828f3ec0 ← handle 0x1004
CTOR-PROBE pc=0x82181750 tid=1 hw=0 cycle=5363599 r3=0x828f3d08 ← handle 0x100c
CTOR-PROBE pc=0x821701c8 tid=1 hw=0 cycle=9203618 r3=0x828f4070 ← handle 0x15e0
```
So **handle 0x1004 has a SINGLE dispatcher at `0x828F3EC0`**, not 8
pool members. The earlier "called 8 times" claim from AUDIT-002/003
came from raw-counting OUTER getter `sub_8217C850` entries — but that
outer is itself a Meyers-style singleton getter (gates `bl
0x821783D8` on `[0x828F48D8] bit 0`); only the FIRST entry cascades
through to the per-instance ctor. Subsequent entries return the
existing slot pointer and are no-ops for our purposes.
### 2. Producer indirection IS the Meyers singleton-getter
Static byte-scan of `.rdata` and `.data` (PE at
`Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).pe`) for
the 4-byte BE encodings of 0x828F3D08 / 0x828F4070 yields **0 hits**
in either section. So no static registry table holds these
addresses. But the `xrefs` table for the outer getters
(`sub_821800D8` for 0x100c, `sub_8216F618` for 0x15e0) reveals 5–6
callers each, all sharing the canonical producer pattern:
```asm
bl outer_singleton_getter ; r3 = dispatcher ptr (returned)
lwz r3, OFFSET(r3) ; r3 = field at OFFSET (event handle / wake target)
bl 0x824AA1D8 ; signal/wake function
```
OFFSETS: 80 (= 0x50) for 0x100c, 36 (= 0x24) for 0x15e0.
**Non-create-chain consumer sites** (these are the producer-hunt
targets for the next session):
```
sub_821800D8 (outer for 0x828F3D08, handle 0x100c) — 5 producer callers:
0x821802d8 (sub_82180158+0x180)
0x821806e0 (sub_821805C8+0x118)
0x82180b28 (sub_82180A10+0x118)
0x82180ea0 (sub_82180D90+0x110)
0x82181254 (sub_821810E0+0x174)
;; 0x82181c54 (sub_82181C28+0x2C) is the create-chain (skip)
sub_8216F618 (outer for 0x828F4070, handle 0x15e0) — 4 producer callers:
0x8216f9d4 (sub_8216F818+0x1BC)
0x8216fc08 (sub_8216F9F0+0x218)
0x821700b8 (sub_8216FF70+0x148)
0x821700f4 (sub_821700E0+0x14)
;; 0x821707f4 (sub_821707C0+0x34) is the create-chain (skip)
```
So the AUDIT-003 xref-audit conclusion ("every reference is in a
ctor or the CRT") was correct in the literal sense (every direct
dispatcher-base xref) but missed the **indirection layer**. The
producers don't reference 0x828F3D08 / 0x828F4070 directly —
they call the outer getter and dereference the returned pointer.
**Interpretation (2) of the audit charter is confirmed.**
### 3. Dispatcher struct layouts (128-byte dumps)
```
0x828F3D08 (handle 0x100c, ctor sub_82181750):
+0x00 = 0xFFFFFFFF ; queue head/tail sentinel
+0x28 = 0x00000007 ; capacity = 7
+0x2C = 0x01000000 ; init flag (BE)
+0x3C = 0xFFFFFFFF ; secondary sentinel
+0x48 = 0x00001010 ; thread_handle (worker)
+0x4C = 0x0000100C ; event_handle (= self)
+0x50 = 0x00000000 ; ← producer reads this (currently 0)
+0x70 = 0x00000001 ; refcount?
+0x74 = 0x828F3D08 ; self-pointer
0x828F4070 (handle 0x15e0, ctor sub_821701C8):
+0x00 = 0x01000000 ; init flag
+0x10 = 0xFFFFFFFF ; queue sentinel
+0x1C = 0x000015E4 ; sibling-handle (NOT in our parked set)
+0x20 = 0x000015E0 ; event_handle (= self)
+0x24 = 0x00000000 ; ← producer reads this (currently 0)
+0x40 = 0xFFFFFFFF ; secondary sentinel
0x828F3EC0 (handle 0x1004, ctor sub_821783D8):
+0x00 = 0x01000000 ; init flag
+0x10 = 0xFFFFFFFF ; queue sentinel
+0x20 = 0x40541BC0 ; heap pointer (sub-buffer #1)
+0x30 = 0x00000014 ; size 20
+0x34 = 0x0000002F ; size 47
+0x3C = 0x40211CA0 ; heap pointer (sub-buffer #2)
+0x44 = 0x405418C0 ; heap pointer (sub-buffer #3)
+0x50 = 0x40111840 ; heap pointer (sub-buffer #4)
+0x58 = 0xFFFFFFFF / +0x5C = 0xFFFFFFFF ; sentinels
+0x76 = 0x000012AC ; possibly thread id
+0x78 = 0x00001004 ; event_handle (= self)
```
The 0x1004 dispatcher is **structurally distinct** — it owns 4
guest-heap (0x4xxxxxxx) sub-buffers, suggesting a richer
resource-managing subsystem rather than a pure POD job queue.
Each handle's struct uses a different event-handle offset
(0x4C / 0x20 / 0x78), so they are NOT instances of a shared
base class — three distinct subsystem types.
## Reproduce
```bash
cargo run --release -p xenia-app -- exec 'sylpheed.iso' \
--halt-on-deadlock \
--trace-handles-focus=0x1004,0x100c,0x15e0 \
--ctor-probe=0x821783D8,0x82181750,0x821701C8 \
--dump-addr=0x828F3D08,0x828F4070,0x828F3EC0 \
-n 50000000
```
Trace files:
- `audit-runs/audit-004/run-50m-probe.txt` (outer-getter PC probes — many hits per session)
- `audit-runs/audit-004/run-50m-probe-v2.txt` (inner-ctor probes — 1 hit each, singleton confirmation)
## Recommendation for next session (do not implement a fix)
**Hook the 9 non-create-chain consumer sites** to determine which
of two failure modes is actual:
```bash
cargo run --release -p xenia-app -- exec 'sylpheed.iso' \
--halt-on-deadlock \
--trace-handles-focus=0x1004,0x100c,0x15e0 \
--ctor-probe=0x821802d8,0x821806e0,0x82180b28,0x82180ea0,0x82181254,\
0x8216f9d4,0x8216fc08,0x821700b8,0x821700f4 \
-n 500000000
```
- **Failure mode A (producer never reached)**: none of the 9 PCs
fire. The producer chain is gated upstream — likely a feature
flag, init phase, or RPC handler that never executes. Trail
leads back to the function-pointer table being walked or the
scheduler-driven event source.
- **Failure mode B (producer fires but signals zero)**: some PCs
fire. The dispatcher field at the producer's offset (+0x50 for
0x100c; +0x24 for 0x15e0) was never populated, so `lwz r3,
OFFSET(r3)` reads zero and `bl 0x824AA1D8` is called with
handle=0. Then the next bug is "who SHOULD populate that field
and doesn't" — read the OWNING subsystem's setup path.
Both failure modes are answerable in one read-only probe run.
For handle 0x1004's separate-track investigation: dispatcher
0x828F3EC0 has 4 heap sub-buffers in 0x4xxxxxxx range. The pool
of buffers (not the singleton dispatcher itself) might be the
"8 instances" intuition that drove AUDIT-003's mislabel. Worth
dumping each sub-buffer to see if THEY look like 8 elements.
## Engineering gotchas worth remembering
- **Meyers-singleton getters look identical to per-instance
ctors** when probed naively. The trick is the init-flag check
at the top: `lwz r11, FLAG; rlwinm r9, r11, 0, 31, 31; cmpli
cr6, 0, r9, 0; bc 4, 4*cr6+eq, RETURN_PATH`. The first call
passes, sets the flag, falls through to the inner ctor. All
subsequent calls hit the bypass branch. Counting outer-getter
entries (= "called 8 times") is meaningless; only the first is
a real construction event.
- **xref-table audit is necessary but NOT sufficient.** It
catches direct constant-loads of an address but misses
function-pointer indirection (singleton getters, vtable
dispatch, registered-callback tables). When a static-analysis
audit says "no producer references X", it actually means "no
direct constant-load reference"; you still need to check
whether functions that RETURN X have additional callers.
- **Static-byte-scan of .rdata / .data is fast and cheap to
rule out hidden registry tables.** The Python recipe used
here:
```python
with open('image.pe', 'rb') as f: data = f.read()
needle = struct.pack('>I', 0x828F3D08)
while True:
i = blob.find(needle, start)
if i < 0: break; ...
```
In sub-second on this image. If this returns hits at non-self
addresses, you have a registry indirection in addition to (or
instead of) any singleton-getter pattern.
- **Probe on `bl` arrival**, not on `bl` source PC. We probe on
the FIRST instruction of the ctor function (e.g. 0x821783d8),
capturing live r3 = `this`. That works because PPC `bl`
passes the first arg in r3 by ABI. If you probe on the bl
call site instead, you have to read forward in the
instruction stream to find what r3 is at the call point.
## Files
- `crates/xenia-kernel/src/state.rs` — `ctor_probe_pcs`,
`dump_addrs`, `fire_ctor_probe_if_match`, 2 unit tests.
- `crates/xenia-app/src/main.rs` — `--ctor-probe` /
`--dump-addr` CLI parsing, prologue hook, end-of-run dumper.
- `audit-findings.md` — KRNBUG-AUDIT-004 entry (after KRNBUG-
AUDIT-003).
- `audit-runs/audit-004/run-50m-probe.txt` — outer-getter
probe (28 hits showing many-call pattern of sub_8217C850).
- `audit-runs/audit-004/run-50m-probe-v2.txt` — inner-ctor
probes (3 hits total, one per per-instance ctor — singleton
hypothesis confirmed).

141
migration/claude-memory/project_xenia_rs_audit_005_priv_stub_2026_05_04.md Normal file
View File

@@ -0,0 +1,141 @@
---
name: KRNBUG-AUDIT-005 — XexCheckExecutablePrivilege stub gates init flow
description: 2026-05-04 audit. PC-probe + canary kernel-call diff identified XexCheckExecutablePrivilege returning 0 as the upstream gate that skips XGetAVPack, XeCrypt*, XamTaskSchedule init flow — explains why producers for parked-waiter handles 0x1004/0x100c/0x15e0 are unreached.
type: project
originSessionId: 3ca68be8-9f51-47ec-8f5f-1227affcc3d7
---
# KRNBUG-AUDIT-005 (2026-05-04, LANDED master)
## What landed
Combined-session diagnostic per the user prompt:
1. **`--pc-probe=PC[@DISPATCHER:OFFSET][,...]` extension** — generalized
the existing `--ctor-probe` machinery so each token can additionally
capture the dispatcher field that the `bl outer_getter; lwz r3,
OFF(r3); bl 0x824AA1D8` producer pattern is about to read. Reused
`parse_hex_u32`. `--ctor-probe` and `--pc-probe` now share parser +
storage (single helper, no duplication). New env var
`XENIA_PC_PROBE` is an alias for `XENIA_CTOR_PROBE`.
2. **Reused existing `probe_calls` trace target** — no new
kernel-call tracing infrastructure needed. The pre-existing
`tracing::trace!(target: "probe_calls", ...)` in
`state.rs::call_export` produces a kernel-call sequence comparable
to canary's once filtered through `--log-filter='probe_calls=trace'`.
## Decisive findings
### α confirmed: producer code path never reached
All 9 non-create-chain consumer call sites for handles 0x100c (5
sites) and 0x15e0 (4 sites) — the canonical producer pattern from
KRNBUG-AUDIT-004 — fire **0×** at -n 500M
(`grep -c CTOR-PROBE audit-runs/audit-005/ours.log == 0`). Failure
mode (B: lwz reads zero) and (3: wake function called with stale
handle) are RULED OUT. The bug is upstream.
### Upstream divergence located: `XexCheckExecutablePrivilege` stub
Set-diff of kernel-call sequences (canary as oracle, ours from -n
500M) shows **11 exports canary calls and we don't**:
```
ExTerminateThread (×2), KeReleaseSemaphore (×268), KeResetEvent (×1),
NtDeviceIoControlFile (×2), ObCreateSymbolicLink (×1), XGetAVPack (×1),
XamTaskCloseHandle (×1), XamTaskSchedule (×1),
XamUserReadProfileSettings (×2), XeCryptSha (×1),
XeKeysConsolePrivateKeySign (×1)
```
**`XGetAVPack` has exactly one caller**, `0x824AB5A0` inside
`sub_824AB578`. Disasm:
```
824ab58c addi r3, r0, 10 ; privilege bit 10
824ab594 bl 0x8284DEFC ; XexCheckExecutablePrivilege
824ab598 cmpli 0, r3, 0x0
824ab59c bc 12, eq, 0x824AB724 ; if r3==0, skip whole block
```
`crates/xenia-kernel/src/exports.rs:193` registers
`XexCheckExecutablePrivilege` as `stub_return_zero`. Always returning
0 → guest takes the `bc 12, eq` branch → skips XGetAVPack +
XeCryptSha + XeKeysConsolePrivateKeySign + ObCreateSymbolicLink +
XamUserReadProfileSettings + the long `NtWriteFile` save-data block.
The OTHER caller (`sub_824A9710` at `0x824A99A0`) queries privilege
**11** with **opposite polarity** (`bc 4, eq` = bne) — both stubs
returning 0 means the guest walks the wrong arm of every
privilege-gated branch. This is the gate to `XamTaskSchedule` and
the XAM init flow that AUDIT-002 identified as a producer
candidate.
### Cascade explanation
The dispatcher structs at `0x828F3D08`, `0x828F4070`, `0x828F3EC0`
have their per-instance ctors fired (KRNBUG-AUDIT-004 verified —
each fires once). But the dispatcher *fields* the producer is
about to read remain zero (`[0x828F3D08+0x50] = 0`,
`[0x828F4070+0x24] = 0` from AUDIT-004 dumps). Now we know why:
the **producers** that would populate those fields with a non-zero
handle never execute, because the upstream init flow (gated by
the privilege checks) is skipped. The ctor sets up the dispatcher
struct shell; the producer (somewhere in the
XGetAVPack/XeCrypt/XamTaskSchedule chain) populates it with the
worker-event handle. We never reach the producer.
### Note on canary log filtering
Canary's config has `log_high_frequency_kernel_calls = false`. The
"called in OURS but not canary" side of the diff (23 entries, headed
by `NtWaitForSingleObjectEx ×1.5M`) is dominated by this filter
difference, **not** a bug surface. Always work from the directionally
meaningful side: "called in CANARY but not OURS".
## Verification
- 588 tests pass before and after.
- Lockstep golden `sylpheed_n50m` matches: `run digest matches
golden` at -n 50M `--stable-digest`.
- The new `pc_probe_consumers` field is empty by default; existing
ctor-probe tests cover the shared infrastructure.
## Next session — recommendation
Replace `XexCheckExecutablePrivilege` stub with a real impl:
1. Parse `XEX_HEADER_EXECUTION_INFO` privilege bits at XEX load
time into `KernelState` (or surface via existing VFS XEX metadata).
See `crates/xenia-xex/` for the XEX header parser; `KernelState`
already holds `image_base`.
2. `xex_check_executable_privilege(priv_id)`: return 1 if bit
`priv_id` is set in the title's privilege bitmask. Encoding:
`PrivilegeFlags[priv_id / 8] & (1 << (priv_id % 8))` — match
canary's reading.
3. Re-run `audit-runs/audit-005/diff.py`. Expect `XGetAVPack`,
`XamTaskSchedule`, `XeCryptSha`, etc. to appear in our sequence.
4. Re-run with the 9-PC probe armed at -n 500M. At minimum the
ctor-probe trail changes; ideally producer sites start firing.
5. If producer sites fire, dispatcher fields populate (verify with
`--dump-addr=0x828F3D08,0x828F4070`).
6. Lockstep golden `sylpheed_n50m.json` will change — `imports`
counter rises, `swaps` may advance. Regenerate under
`--stable-digest` as the new anchor.
## Files
- `crates/xenia-kernel/src/state.rs` — `pc_probe_consumers` field
+ extended `fire_ctor_probe_if_match` (~12 added lines).
- `crates/xenia-app/src/main.rs` — `--pc-probe` clap alias +
`PC@DISP:OFF` parser (~20 added lines).
- `audit-runs/audit-005/canary.log` — copy of
`/home/fabi/xenia_canary_windows/xenia.log`.
- `audit-runs/audit-005/ours.log` — 838 MB / 5.6 M lines @ -n 500M.
- `audit-runs/audit-005/diff.py` — one-shot Python diff (set-diff +
first-divergence window). Deletable after the fix lands.
- `audit-findings.md` KRNBUG-AUDIT-005 — full deliverable.
## Master HEAD after merge
`451b3b2` — Merge canary-diff-and-pc-consumer-probe/p0-priv-stub-cascade
(feature commit: `3e2fc1e`).

78
migration/claude-memory/project_xenia_rs_audit_006_export_queue_2026_05_04.md Normal file
View File

@@ -0,0 +1,78 @@
---
name: KRNBUG-AUDIT-006 (canary-only export fix queue)
description: 2026-05-04 read-only audit; 7/7 canary-only exports classify REAL_BUT_UNREACHED → upstream gate is KRNBUG-IO-002 block-size mismatch
type: project
originSessionId: c7ccc670-90c6-409b-b2d4-71dd9a133de2
---
# 🎯 KRNBUG-AUDIT-006 (2026-05-04, READ-ONLY SESSION)
**Headline:** the post-IO-001 canary-only export list is **identical** to
IO-001's snapshot (7 entries, no movement). All 7 classify as
REAL_BUT_UNREACHED or STUB_BUT_UNREACHED. Per stop conditions, the next
session must fix the **upstream gate**, not pull from this queue.
## Pre-state
- Master HEAD `556a8c3`. Tests 591 green.
- Trace: `xenia-rs/audit-runs/audit-006/ours.log` (692 MB, -n 500M, post-IO-001).
- Oracle: `xenia-rs/audit-runs/audit-006/canary.log` (348 KB, deterministic; canary `9467c77f0`).
- Diff: `comm -23` on extracted call names → 7 canary-only entries, identical to IO-001 list.
## The 7 canary-only entries (all Tier 4)
`XamTaskSchedule`, `XamTaskCloseHandle`, `KeResetEvent`,
`ObCreateSymbolicLink`, `KeReleaseSemaphore`, `ExTerminateThread`,
`XamUserReadProfileSettings`. 5 of 7 are real impls in our code; 2
(`XamTaskCloseHandle`, `ObCreateSymbolicLink`) are `stub_success`. None
fires at -n 500M. All first calls in canary fall **after** line 1210
(the `XamTaskSchedule(824A93C8, ...)` gate-pivot).
## The gate (Tier 0 — what next session works on)
**KRNBUG-IO-002 — `nt_query_volume_information_file` block size**
(`crates/xenia-kernel/src/exports.rs:1241-1269`).
- Class=3 returns `(sectors=1, bytes_per_sector=2048)` → alloc_unit=2048.
- Sylpheed expects 65536 (`main(1, 0x10000, 0xFF000)`); game's
`sub_824ABA98` (VerifyDirBlockSize) silently rejects, propagates failure
to `sub_824A9710`, which exits before its `XexCheckExecutablePrivilege(0xB)`
+ `XamTaskSchedule` call sites. Confirmed: our `XexCheckExecutablePrivilege`
count = 1 (priv=0xA only); canary count = 2 (priv=0xA + 0xB).
- Canary's NullDevice (`xenia-canary/src/xenia/vfs/devices/null_device.h:38-46`)
returns `(0x80, 0x200)` = 65536 — the value Sylpheed expects.
- **Fix:** two-line value change in the class=3 branch
(`sectors=128, bytes_per_sector=512`).
- **Expected cascade post-fix:** XamTaskSchedule fires → Cache0 callback
thread spawns → `ObCreateSymbolicLink` + `ExRegisterTitleTerminateNotification`
+ `KeResetEvent(0x8287094C)` + `ExCreateThread(entry=0x82181830,
ctx=0x828F3D08)`. The latter is the worker for **dispatcher 0x100c**
(one of the four parked-handle producers). Closing IO-002 should drop
the 7-entry list to 0 or near-0 and finally advance handle 0x100c's
signal_attempts off zero.
## Surprises / corrections to prior beliefs
- **`0xC000014F` from IO-001 memory's prediction has not appeared in
ours.log.** First cache-related error is `0xC0000034`
(OBJECT_NAME_NOT_FOUND) from `lr=0x824a97e4`. The recreate path
completes its 44 NtWriteFile calls; the failure is *game-side* in
the verifier, not a kernel-returned NTSTATUS. Gate hypothesis still
holds; the specific status code in IO-001 memory was speculative.
- **No new canary-only exports surfaced post-IO-001.** The cascade has
not opened any new boot territory since IO-001 landed.
- **Tier 1 / 2 of the queue are empty.** This is the expected outcome
per the spec's stop conditions, not a defect of the audit.
## Deliverable
`xenia-rs/audit-runs/audit-006/canary_export_queue.md` (216 lines)
documents the classification, the gate, fix sketches, and the
post-fix verification chain. **Do not** pull Tier 4 entries from it
before IO-002 closes.
## Recommended next session
KRNBUG-IO-002, one-shot (≤ 4 LOC). Re-run audit-006's diff after the
fix; expect canary-only count 7 → 0 (or near-0). Whatever new
canary-only entries surface (if any) become audit-007 input. Land
the producer-hunt finally.

145
migration/claude-memory/project_xenia_rs_audit_007_branch_probe_2026_05_04.md Normal file
View File

@@ -0,0 +1,145 @@
---
name: KRNBUG-AUDIT-007 — sub_824A9710 exit gate identified (NtDeviceIoControlFile FsCtl 0x74004 stub)
description: 2026-05-04. Branch-probe trace landed sub_824A9710 entry; r3=0xC0000034 captured at 0x824a97e0 (failure landing pad). Exit branch=0x824a9944 (post bl sub_824ABD88 first call). Root cause: NtDeviceIoControlFile registered as stub_success — game-side sub_824ABD88 reads [out_buf+8] from the 16-byte response of FsCtlCode=0x74004, finds zero, and assigns hardcoded 0xC0000034 (STATUS_OBJECT_NAME_NOT_FOUND). Diagnostic only — no fix this session.
type: project
originSessionId: 63d3490e-a119-46d9-960e-f11684a5e2a2
---
🎯 **KRNBUG-AUDIT-007 (2026-05-04, READ-ONLY DIAGNOSTIC, branch `investigate-sub-824a9710/p0-branch-probe`)** — branch-probe instrumentation landed; runtime trace decisively identifies the exit gate downstream of IO-001/IO-002. The priv-11 site at `sub_824A9710:0x824a99a0` is gated by `NtDeviceIoControlFile(FsCtlCode=0x74004)` which is currently registered as `stub_success` at `crates/xenia-kernel/src/exports.rs:90`.
## Decisive runtime evidence
`audit-runs/audit-007/sub_824A9710-trace.log`:
```
BRANCH-PROBE pc=0x824a9aa0 tid=1 hw=0 cycle=5362945 r3=0x00000001 lr=0x8216eaa0 cr0=..E cr6=..E
BRANCH-PROBE pc=0x824a9128 tid=1 hw=0 cycle=5362957 r3=0x00000001 lr=0x824a9abc cr0=..E cr6=..E
BRANCH-PROBE pc=0x824a9710 tid=1 hw=0 cycle=5363003 r3=0x00000000 lr=0x824a9acc cr0=L.. cr6=..E
BRANCH-PROBE pc=0x824a97e0 tid=1 hw=0 cycle=5369559 r3=0xc0000034 lr=0x824a9940 cr0=L.. cr6=L..
BRANCH-PROBE pc=0x824a9a98 tid=1 hw=0 cycle=5369562 r3=0x00000002 lr=0x824a97e4 cr0=L.. cr6=L..
```
**Reading the trace:**
- Cycle 5362945: `main()` (sub_8216EA68) calls `sub_824A9AA0(r3=1, r4=0x10000, r5=0xFF000)` at PC 0x8216ea9c, return at 0x8216eaa0. ✅ Function chain reached.
- Cycle 5363003: `sub_824A9710` entered with r3=0 (sub_824A9128 returned 0 — its inner sub_824A90A8 returned negative, expected for first-time cache load).
- Cycle 5369559: PC=`0x824a97e0` (failure landing pad), r3=`0xc0000034`, lr=`0x824a9940` (the `cmpi 0,r3,0` at PC after `bl 0x824ABD88`).
- Cycle 5369562: PC=`0x824a9a98` (epilogue) — function returns 0xC0000034 to caller `sub_824A9AA0`, which discards it.
**Translation:** the `bl sub_824ABD88` at `0x824a993c` returned `0xC0000034` (STATUS_OBJECT_NAME_NOT_FOUND). The branch at `0x824a9944` (`bc 12, lt, 0x824A97E0`) was TAKEN, exiting the function before reaching the priv-11 query at `0x824a99a0`.
**Cycle budget for path** (`5369559 − 5363003 = 6556` instructions): consistent with prologue + 2× memset + 3 early-exit checks + NtCreateFile (~thunk + HLE) + NtReadFile (~thunk + HLE, IO-001 path returns success+0) + magic mismatch → recreate setup at 0x824a98bc + sub_824ABD88 internals (sub_824ABC88 + NtOpenFile + NtDeviceIoControlFile×2 + NtClose). Maps cleanly onto the canary.log lines 1141-1208 prefix.
## Mechanical chain to 0xC0000034 (cross-checked vs disasm)
`sub_824ABD88` (the gate) full disasm at `0x824abd88-0x824ac184` (the function is 254 insns; sylpheed.db's `end_address=0x824abe3c` was a function-detection truncation — actual end is at `0x824ac184` confirmed by disassembling forward).
Path through `sub_824ABD88`:
1. `bl sub_824ABC88` at `0x824abda8` returns 0 (input ANSI string `\Device\Harddisk0\Cache0` mismatches the `\Device\Harddisk0\Partition1` literal at 0x820015A4 — early fast-path return inside sub_824ABC88).
2. `bl NtOpenFile` at `0x824abde0` (object name = caller's r31 = `\Device\Harddisk0\Cache0`, access=0x100003, options=0x18). Per our `open_vfs_file` synthesizes empty file → returns SUCCESS.
3. `bl NtDeviceIoControlFile` at `0x824abe1c` — first IOCTL: `(handle, 0,0,0, iosb=r1+112, fsctl=0x70000, 0,0, out_buf=r1+120, out_len=8)`. Stub returns SUCCESS, doesn't write OUT.
4. `lwz r11, 124(r1)` at `0x824abe3c` reads byte-pos within first OUT (= 0). cntlzw + subfic computes `r11 = 31 - 32 = -1`, but `bc 12, 4*cr6+eq, 0x824ABE54` takes the `r11==0` branch → `r11 = 0`. Stored in `r22 = 0`.
5. `bl NtDeviceIoControlFile` at `0x824abe90` — second IOCTL: `(handle, 0,0,0, iosb=r1+112, fsctl=0x74004, 0,0, out_buf=r1+160, out_len=16)`. Stub returns SUCCESS, doesn't write OUT.
6. `cmpi 0, r3, 0` / `bc 12, lt, 0x824ABEB8` — r3=0 ≥ 0, fall through.
7. **`ld r10, 168(r1)`** — loads doubleword from `[r1+160+8]` = upper 8 bytes of the 16-byte OUT buffer. Stub left it whatever it was → ZERO (fresh stack frame post-stwu).
8. `cmpi cr6, 1, r10, 0` (L=1, doubleword cmp). r10=0 → cr6.eq=1.
9. `bc 4, 4*cr6+eq, 0x824ABEB0` — BO=4 = branch-if-FALSE; cond=eq is TRUE; **does NOT branch** → falls through to:
10. **`addis r3, r0, 0xC000`** at `0x824abea8` followed by **`ori r3, r3, 0x34`** at `0x824abeac` — **r3 := 0xC0000034 (STATUS_OBJECT_NAME_NOT_FOUND), HARDCODED**.
11. `cmpi cr6, 0, r3, 0` / `bc 4, 4*cr6+lt, 0x824ABECC` — r3=0xC0000034 negative, cr6.lt=1, BO=4 = branch-if-FALSE — does NOT branch → falls through to:
12. `or r28, r3, r3` (`0x824abeb8`) → save 0xC0000034 → `bl NtClose` (`0x824abec0`) → `or r3, r28, r28` (`0x824abec4`) → `b 0x824ABE34` (epilogue) — **return 0xC0000034 to caller**.
Caller `sub_824A9710` at `0x824a9940`: cmpi shows r3 < 0, bc 12, lt at `0x824a9944` is TAKEN → branches to `0x824a97e0` (the failure landing PC the probe captured).
## What canary does at this site
`audit-runs/post-IO-002/canary.log` lines 1196-1208:
```
NtOpenFile(701CF390(00000000), 00100003, 701CF3C0(00000000,\Device\Harddisk0\Cache0,00000040), 701CF3A0, 00000000)
NtDeviceIoControlFile(F8000010, 00000000, 00000000, 00000000, 701CF3A0, 00070000, 00000000, 00000000, 701CF3A8, 00000008)
NtDeviceIoControlFile(F8000010, 00000000, 00000000, 00000000, 701CF3A0, 00074004, 00000000, 00000000, 701CF3D0, 00000010)
NtWriteFile × 17 (zero-fill 64KB cluster)
KeQuerySystemTime
NtWriteFile (commit final block)
undefined extern call to 8284E0DC IoDismountVolumeByFileHandle
NtClose
NtOpenFile(701CF3F0(00000000), 00100001, 701CF400(00000000,\Device\Harddisk0\Cache0\,00000040), 701CF3F8, 00000003)
NtQueryVolumeInformationFile(F8000010, 701CF3F8, 701CF410, 00000018, 00000003)
NtClose
XexCheckExecutablePrivilege(0000000B) ← priv-11 site fires
XamTaskSchedule(824A93C8, 828A28F0, 701CF4C0, 701CF4A4(00000000), ContextArg)
```
Canary's `NtDeviceIoControlFile` for FsCtlCode=0x74004 returns SUCCESS *and* populates the 16-byte OUT buffer at `701CF3D0`. The exact payload isn't logged, but the buffer's upper-8-bytes is non-zero (otherwise canary would also hit the 0xC0000034 trap), and from the post-IOCTL flow the value is consumed as a partition-size or address to drive the 17× NtWriteFile zero-fill loop.
Per `xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_io.cc` (NtDeviceIoControlFile_entry) + `xenia-canary/src/xenia/vfs/devices/null_device.{h,cc}` (NullDevice::IoControl), each device implements `IoControl` and writes the payload. FsCtlCode `0x74004` decodes to (DEVICE=`FILE_DEVICE_DISK`, FUNCTION=0x1001, METHOD=`METHOD_BUFFERED`) — likely `IOCTL_DISK_GET_PARTITION_INFO` or a Xbox-specific equivalent. FsCtlCode `0x70000` = (DEVICE=DISK, FUNCTION=0, METHOD=BUFFERED) — `IOCTL_DISK_GET_DRIVE_GEOMETRY` candidate.
## Next-session fix target (KRNBUG-IO-003)
**Where:** `crates/xenia-kernel/src/exports.rs:90`. Replace `stub_success` registration with a real `nt_device_io_control_file` handler.
**Minimum viable fix:**
The game-side check at `sub_824ABD88:0x824abe9c-0x824abeb4` only requires that **`[out_buf+8]` is non-zero** when FsCtlCode=0x74004. That alone moves us past the gate. A canary-faithful fix populates the full 16-byte OUT buffer; the minimum fix writes any non-zero doubleword at offset 8.
**Canary-faithful fix:**
Mirror canary's `NullDevice::IoControl` for FsCtlCode 0x74004 (and 0x70000 for the prior call). Reference: `xenia-canary/src/xenia/vfs/devices/null_device.cc`. The FsCtlCode signature dispatch should also fall through to `STATUS_NOT_IMPLEMENTED` for unknown codes (instead of silent SUCCESS) to surface future divergences early.
**Effort:** small (~30-50 LOC for two FsCtlCode branches + canary structure-match fixture test). FsCtlCode value extraction + payload writing — no new types needed.
**Risk:** low for the minimum fix (one IOCTL response). Medium for the full canary-faithful path (matches canary's NullDevice exactly, with possible regression risk for the 0x70000 path if any other site queries it).
## Cascade prediction (sharp, falsifiable)
Post-IO-003 fix, lockstep at -n 500M:
- `XexCheckExecutablePrivilege` count: **1 → 2** (priv=0xA + priv=0xB).
- `XamTaskSchedule` count: **0 → 1** (callback=0x824A93C8, message=0x828A28F0).
- canary-only export count: **7 → ≤ 3**. The 4 entries that should drop:
- `XamTaskSchedule` (immediate fire).
- `KeResetEvent` (post-cluster, on `KeResetEvent(0x8287094C)`).
- `ObCreateSymbolicLink` (alt path at `sub_824A9710:0x824a9a6c` if priv-11 returns 0; or in the inner Cache0 cluster).
- `XamTaskCloseHandle` (cleanup after task completes).
- Worker thread spawn at `ExCreateThread(entry=0x82181830, ctx=0x828F3D08)` — **handle 0x100c's parked-waiter producer fires**, advancing `signal_attempts` off zero for one of the three parked handles.
- `swaps`: **2 → 2** (renderer plateau is multi-causal — closing this gate doesn't directly unblock the renderer, but unparks one worker).
## Falsification guards (what would invalidate the prediction)
- **(α)** If KeResetEvent / ObCreateSymbolicLink / XamUserReadProfileSettings / etc. each have additional unimplemented kernel-call dependencies, the cascade stops at the first one. Detectable by re-running `--branch-probe` over `sub_824A9710` and observing a NEW exit branch (any of: 0x824a996c, 0x824a9998, 0x824a9a18) — OR a hit at sub_824ABA98's analogous failure path.
- **(β)** If `sub_824ABA98` (called at `0x824a9950` and `0x824a9990` in sub_824A9710) has its own unimplemented dependency, we'll exit at `0x824a9998` after the second sub_824ABA98 retry.
- **(γ)** If our `nt_write_file` doesn't handle the synthesized empty-file Cache0 path correctly (a write to a zero-byte file), the 17× NtWriteFile zero-fill in canary's flow may surface a fresh failure between IOCTL and priv-11. Probe will catch this as a hit at `0x824a9998` or downstream.
## Files added / modified this session (instrumentation only — read-only)
- `crates/xenia-kernel/src/state.rs` — added `branch_probe_pcs: HashSet<u32>` field + `fire_branch_probe_if_match(hw_id)` helper. Sister to `fire_ctor_probe_if_match` but emits a single compact `BRANCH-PROBE` line (no back-chain) including cr0/cr6 flags. ~40 LOC.
- `crates/xenia-app/src/main.rs` — added `--branch-probe` CLI flag (env-var `XENIA_BRANCH_PROBE`), parser, and call in `worker_prologue` after `fire_ctor_probe_if_match`. ~30 LOC.
- No state mutated; lockstep digest unchanged. 592 → 592 tests. Two reruns of `check -n 100000010 --stable-digest` produced bit-identical output (`audit-runs/audit-007/lock_post_branchprobe.json` ≡ `lock_post_branchprobe_run2.json` ≡ `audit-runs/post-IO-002/lock_n100m_run1.json`).
## Trace artifacts (re-runnable)
- `audit-runs/audit-007/sub_824A9710-trace.log` — 5 BRANCH-PROBE lines + thread diagnostics.
- `audit-runs/audit-007/sub_824A9710-trace.err` — full kernel-call trace + counter dump (635 lines).
- `audit-runs/audit-007/lock_post_branchprobe.json`, `lock_post_branchprobe_run2.json` — lockstep digest reruns.
Re-run command:
```
PROBE_LIST="0x824a9aa0,0x824a9128,0x824a9710,0x824a9778,0x824a9788,0x824a9790,0x824a97dc,0x824a97e0,0x824a9824,0x824a9828,0x824a9840,0x824a9850,0x824a985c,0x824a9870,0x824a9880,0x824a9888,0x824a9918,0x824a9944,0x824a9958,0x824a996c,0x824a9998,0x824a999c,0x824a99a0,0x824a99a8,0x824a9a10,0x824a9a18,0x824a9a60,0x824a9a78,0x824a9a98"
./target/release/xenia-rs exec sylpheed.iso --halt-on-deadlock --branch-probe="$PROBE_LIST" -n 500_000_000 \
> audit-runs/audit-007/sub_824A9710-trace.log 2> audit-runs/audit-007/sub_824A9710-trace.err
```
## Probe-machinery limitation noted
The `--branch-probe` helper fires only at PC values that are block-heads (i.e., the start of an interpreter dispatch unit). Mid-block PCs in the request set don't trigger because the prologue runs once per block, not once per instruction. In this trace, the function entry, failure landing pads (`0x824a97e0`, `0x824a9a98`), and external-call return points get probed, while internal `bc` PCs are silent. The data captured was sufficient — the failure landing PC + LR pair uniquely identifies the upstream branch — but if a future audit needs every-instruction granularity, the call site needs to move from `worker_prologue` to inside the per-instruction step in `step_block`.
## Cross-check vs prior memory
- `project_xenia_rs_io_002_volallocunit_2026_05_04.md` listed three next-session-gate hypotheses. **Hypothesis 1 confirmed** (sub_824A9710 entry-side probe found the gate). **Hypothesis 2** (different info-class) was wrong direction — the gate is an IOCTL not an info-class. **Hypothesis 4** (different IOCTL) was on the right track — the FIRST IOCTL we saw in our log (FsCtlCode `0x70000+0x4004`) is exactly the gate IOCTL.
- `project_xenia_rs_audit_006_export_queue_2026_05_04.md` Tier-0 KRNBUG-IO-002 hypothesis (vol-info block size) was the wrong gate but the framework correctly classified the 7 canary-only exports as REAL_BUT_UNREACHED. The framework's stop condition triggered correctly.
- `project_xenia_rs_audit_005_priv_stub_2026_05_04.md` attribution of `sub_824ABA98 = VerifyDirBlockSize` and `sub_824ABD88 = MaybeMountAndIoctl` was provisional. **`sub_824ABD88 = MaybeMountAndIoctl` confirmed accurate** (it's the function that wraps the partition-init IOCTL flow). `sub_824ABA98` not yet exercised — no runtime evidence either way.
## Stop condition
Per task brief: "DO NOT IMPLEMENT A FIX. This session's job is to identify the exit branch and the responsible kernel call." ✅ Identified. Hand-off complete.

140
migration/claude-memory/project_xenia_rs_audit_008_branch_probe_2026_05_05.md Normal file
View File

@@ -0,0 +1,140 @@
---
name: KRNBUG-AUDIT-008 — 0x100c worker IS spawned post-IO-003; gate is downstream job-submitter
description: 2026-05-05. Branch-probe at the post-priv-11 cluster decisively shows main spawns the 0x100c worker (tid=3, ctx=0x828F3D08, entry=0x82181830); IO-003 memory's "0x100c UNCREATED" claim was wrong. Real next gate is missing calls to the 5 non-create-chain job-submitters of sub_821800D8 (pattern `bl outer_getter; lwz r3, 80(r3); bl 0x824AA1D8`). Diagnostic only — no fix per discipline gate.
type: project
originSessionId: 60e12f9a-ffab-465e-8ec5-d5613371fa20
---
🎯 **KRNBUG-AUDIT-008 (2026-05-05, READ-ONLY DIAGNOSTIC)** — model reset on the IO-003 cascade. The "0x100c UNCREATED" claim from `project_xenia_rs_io_003_ioctl_2026_05_04.md` is **falsified**: the 0x100c worker IS spawned post-IO-003 as `tid=3` with `ctx=0x828F3D08, entry=0x82181830`, parked on its lifecycle event handle 0x1020 (signals=0). The actual next gate is downstream of the create chain, in the 0x82287000-0x82292FFF module range that owns the 5 job-submitters of sub_821800D8.
## Decisive runtime evidence (audit-runs/audit-008/branch-probe.trace)
The probe targeted main's post-XamTaskSchedule path, the 0x100c create chain, and the XamTaskSchedule callback. -n 100M, lockstep mode (matching IO-003 baseline `instructions=100000019`).
```
BRANCH-PROBE pc=0x824a9a14 tid=1 hw=0 cycle=5378562 -- main: post-XamTaskSchedule
BRANCH-PROBE pc=0x824a93c8 tid=2 hw=1 cycle=0 r3=0x828a28f0 lr=0xbcbcbcbc -- spawned thread enters callback
BRANCH-PROBE pc=0x824a9540 tid=2 hw=1 cycle=4232 -- spawned thread past StfsCreateDevice cmpi check
BRANCH-PROBE pc=0x824a9a44 tid=1 hw=0 cycle=5378576 -- main: post-KeWaitForSingleObject(0x8287094C)
BRANCH-PROBE pc=0x824a9a4c tid=1 hw=0 cycle=5378579 -- main: post-KeResetEvent
BRANCH-PROBE pc=0x824a9a98 tid=1 hw=0 cycle=5378596 -- main: sub_824A9710 epilogue
BRANCH-PROBE pc=0x824a9acc tid=1 hw=0 cycle=5378609 -- main: sub_824A9AA0 return
BRANCH-PROBE pc=0x8216eaa0 tid=1 hw=0 cycle=5378617 -- main: bl sub_82181C28 callsite
BRANCH-PROBE pc=0x82181c28 tid=1 hw=0 cycle=5378618 -- main entered sub_82181C28
BRANCH-PROBE pc=0x821800d8 tid=1 hw=0 cycle=5378630 -- main entered sub_821800D8 (singleton getter for 0x100c)
BRANCH-PROBE pc=0x82181750 tid=1 hw=0 cycle=5378645 r3=0x828f3d08 -- main entered sub_82181750 ctor
BRANCH-PROBE pc=0x821817c0 tid=1 hw=0 cycle=5378712 r3=0x00001020 -- post-sub_824A9F18 (lifecycle event=0x1020 created)
BRANCH-PROBE pc=0x82181830 tid=3 hw=2 cycle=0 r3=0x828f3d08 lr=0xbcbcbcbc -- 0x100C WORKER SPAWNED AS tid=3
BRANCH-PROBE pc=0x82181838 tid=3 hw=2 cycle=1 r3=0x828f3d08 lr=0xbcbcbcbc -- past entry thunk
BRANCH-PROBE pc=0x821817fc tid=1 hw=0 cycle=5378786 r3=0x00001024 -- main: post-bl sub_82172370, thread handle=0x1024
BRANCH-PROBE pc=0x82180120 tid=1 hw=0 cycle=5378951 -- main: post-atexit registration
BRANCH-PROBE pc=0x82181c58 tid=1 hw=0 cycle=5378957 r3=0x828f3d08 -- main: bl sub_821800D8 returned
```
**Reading the trace:**
- (1) tid=2 enters the XamTaskSchedule callback at `sub_824A93C8` with `r3=0x828a28f0` — exact match for canary's `XamTaskSchedule(callback=0x824A93C8, message=0x828A28F0, ...)` log line at `audit-runs/post-IO-002/canary.log:1210`. ✓
- (2) tid=2 reaches `0x824a9540` (post-StfsCreateDevice cmpi) at cycle 4232. The branch at `0x824a9544` is `bc 4, lt, 0x824A956C` (BO=4 = branch-if-FALSE, cond=lt → branch if r3 ≥ 0). Stub returned 0 → branch TAKEN → cascade walks past to ObCreateSymbolicLink + ExRegisterTitleTerminateNotification + KeSetEvent + KeWaitForSingleObject(0x8287093C). Mirrors canary's F8000010 thread which **also stops at this same wait** (canary log lines 1217-1231 show F8000010 doing the same calls and then going silent). ✓ NOT a gate.
- (3) tid=1 (main) reaches `0x824a9a14` (post-XamTaskSchedule) at cycle 5378562 — only 6,557 cycles later than the spawned thread's callback entry. The spawned thread already signaled `KeSetEvent(0x8287094C)` so main's `KeWaitForSingleObject(0x8287094C)` at `0x824a9a40` returned immediately.
- (4) Main proceeds through the priv-11 cluster's tail: `KeWaitForSingleObject` (cycle 5378576) → `KeResetEvent(0x8287094C)` (cycle 5378579) → `sub_824A9710` epilogue at `0x824a9a98` (cycle 5378596) → `sub_824A9AA0` return (cycle 5378609) → main resume at `0x8216eaa0` (cycle 5378617).
- (5) Main enters `sub_82181C28` (Meyers singleton getter for `[0x828F3D98]` flag) at cycle 5378618. **First call → flag is zero → falls through to `bl sub_821800D8` at `0x82181c54`.**
- (6) `sub_821800D8` (Meyers singleton getter for the 0x100c dispatcher at `[0x828F3D78]` flag) at cycle 5378630. **First call → flag is zero → falls through to `bl sub_82181750` at `0x82180110`.**
- (7) `sub_82181750` (the actual constructor) entered at cycle 5378645 with `r3=0x828F3D08` (the dispatcher's `this`).
- (8) Inside the constructor, `bl sub_824A9F18` (lifecycle-event allocator) returns `r3=0x1020` (the parked-waiter handle). Stored at `[0x828F3D08+76]`.
- (9) `bl sub_82172370` (ExCreateThread wrapper, called at cycle ≈5378750) successfully spawns the worker — visible in the probe as `BRANCH-PROBE pc=0x82181830 tid=3 hw=2 cycle=0 r3=0x828f3d08 lr=0xbcbcbcbc`. **Decisive: tid=3 IS the 0x100c worker.** Confirmed by handle audit at the run end: `handle=0x00001020 Event(sig=false, mr=true) waiters(tid)=[3]` — same tid waiting on the lifecycle event whose value (0x1020) was returned by `sub_824A9F18` to the constructor.
- (10) Main's `sub_82172370` returns `r3=0x1024` (thread handle, distinct from the lifecycle event 0x1020) at cycle 5378786. Constructor finishes; getter returns. Boot continues.
## Reset of model — corrections to KRNBUG-IO-003 memory
The IO-003 prediction scorecard recorded:
- ✗ `0x100c worker spawn (UNCREATED → created+signaled)` — UNCREATED post-IO-003.
- ✗ `Worker thread spawn count: 19 → higher` — unchanged at 19.
**Both are wrong.** The probe definitively shows the 0x100c worker IS created. The handle audit list in `audit-runs/post-IO-003/exec_trace_focus_500m.log` already shows `handle=0x00001020 Event(sig=false, mr=true) waiters(tid)=[3]` — the worker has BEEN there all along; the IO-003 audit just didn't connect tid=3 to the 0x100c dispatcher.
The actual cascade post-IO-003 is **stronger** than IO-003 thought:
- 0x100c worker: spawned (tid=3, parked on handle 0x1020).
- 0x1004 worker: spawned (tid=11, parked on handle 0x1004) — also previously misclassified.
- 0x15e0 worker: spawned (tid=6, semaphore signal-pump live).
What IS still broken: **none of the 3 parked workers have their lifecycle events signaled.** `signal_attempts=0` for handles 0x1004, 0x1020 (and 0x10c4 = 0x100c's secondary event).
## Where the real gate lives
`sub_821800D8` (the 0x100c singleton getter) has 6 callers via xrefs:
| caller PC | from func | role |
|-----------|-----------|------|
| 0x82181c54 | sub_82181C28 | **create chain** (called by main, runs the ctor) |
| 0x821802d8 | sub_82180158 | job-submitter shim (pattern: `bl getter; lwz r3, 80(r3); bl sub_824AA1D8`) |
| 0x821806e0 | sub_821805C8 | job-submitter shim |
| 0x82180b28 | sub_82180A10 | job-submitter shim |
| 0x82180ea0 | sub_82180D90 | job-submitter shim |
| 0x82181254 | sub_821810E0 | job-submitter shim |
Each of the 5 job-submitters is a 5-instruction leaf (`bl outer; lwz r3, 80(r3); bl sub_824AA1D8`) — the canonical "get-then-enqueue" pattern, where `sub_824AA1D8` is the universal dispatcher-submit primitive that ALSO signals the lifecycle event.
`sub_824AA1D8`'s callers split into:
- 5 from the 0x100c shim cluster above
- 4 from the 0x15e0 shim cluster (sub_8216F618 outer getter, offset 36): `0x8216f9dc, 0x8216fc10, 0x821700c0, 0x82170514`
- 1 from inside `sub_82181750` itself at `0x82181924` (the ctor's own self-submit)
The 5 job-submitter shims (sub_82180158, sub_821805C8, sub_82180A10, sub_82180D90, sub_821810E0) are themselves called from the **0x82287000-0x82292FFF module range**:
| shim | shim callers (source func) |
|------|--------------------------|
| sub_82180158 | sub_82292838 (1 caller) |
| sub_821805C8 | sub_822878A8, sub_8228D760, sub_822900A8, sub_822919C8 (4 callers) |
| sub_82180A10 | sub_822878A8 (1 caller) |
| sub_82180D90 | sub_82292838 (1 caller) |
| sub_821810E0 | sub_8228FDB8, sub_82292838 (2 callers) |
The 0x82287xxx-0x82292xxx range is a different code module from the cache/init code. It's almost certainly the renderer / scene-graph subsystem (call sites cluster around the post-XamContentCreateEnumerator content-load path that canary's log shows starting at line 1238). Boot must reach this module to submit its first job; we don't.
## Failure-mode classification (audit-007 schema)
The next gate is **β** (internal sub-recursion / unreached subsystem), NOT **α** (single stubbed import). The 0x100c create chain succeeds end-to-end; the 0x100c worker exists; what's missing is *use* of the 0x100c worker by code in 0x82287xxx-0x82292xxx.
## Discipline gate evaluation (per task brief)
| # | Condition | Pass? |
|---|---|---|
| 1 | Phase 1 named a single kernel/xam import as failing `bl` (branch α) | **NO** — gate is internal logic, not a stub |
| 2 | The import is on the canary-only list or verifiably wrong | N/A |
| 3 | Canary's impl is small (<80 LOC) | N/A |
| 4 | Sharp 4-dimensional cascade prediction | **NO** — would require deeper diagnosis to predict which submitter fires first and what it unblocks |
| 5 | No new ABI plumbing | N/A |
**Gate fails on box 1 + 4. STOP. Hand back per discipline gate.** No code changes this session.
## Open puzzles for next session
1. **Find the FIRST submitter that should fire.** Canary's log between lines 1232 and EOF (5260) shows the post-XamTaskSchedule boot continuation. Specifically, the lines that suggest renderer/scene activation (the 0x100c module is likely renderer-side):
- Line 1238: `XamContentCreateEnumerator` (handle F8000028) — main thread.
- Lines 1240-1256: NtCreateSemaphore, cache:\ NtOpenFile + NtQueryVolumeInformationFile, ExCreateThread(entry=0x8245A5D0).
- Eventually scene/renderer should submit a job to the 0x100c dispatcher.
2. **Probe the candidates.** Add `--branch-probe=0x82292838,0x822878a8,0x8228d760,0x822900a8,0x822919c8,0x8228fdb8` (the parent functions that contain the shim callsites) to a fresh -n 500M run. Whichever fires first identifies the active producer path; whichever fires LAST or never identifies the gate.
3. **Cross-check tid=2's wait target.** The handle-list dump shows `handle=0x8287093c` with waiter tid=2, matching disasm of sub_824A93C8:0x824a95dc-f4 (`addi r27, r11, 2364` with r11=0x82870000 → r27=0x8287093C). The earlier run-state dump's `WaitAny { handles: [2189887804=0x82870EBC] }` reading is a probable diagnostic-text artifact (display delta or stale wait-list field) — not a wrong wait target. **Verify before treating as a bug.**
4. **Wait-target 0x8287093C signals.** `KeSetEvent(0x8287093C)` would unpark tid=2 immediately. In canary's flow, this likely happens far downstream (after the renderer submits enough work that the cache-async-init machinery completes). Don't over-index on this — it's a SECONDARY wait, the primary cascade gate is the missing job-submitter.
## Trace artifacts (re-runnable)
- `audit-runs/audit-008/branch-probe.trace` — 17 BRANCH-PROBE lines (clean extract).
- `audit-runs/audit-008/probe-100m.log` — full stdout (8.7KB).
- `audit-runs/audit-008/probe-100m.err` — full stderr trace (215KB).
Re-run command:
```
cd xenia-rs
PROBE_LIST="0x824a9a10,0x824a9a14,0x824a9a40,0x824a9a44,0x824a9a48,0x824a9a4c,0x824a9a98,0x824a9ac8,0x824a9acc,0x8216eaa0,0x82181c28,0x82181c40,0x82181c48,0x82181c54,0x82181c58,0x82181c88,0x821800d8,0x821800f0,0x821800fc,0x82180110,0x82180120,0x82180138,0x82181750,0x821817bc,0x821817c0,0x821817f8,0x821817fc,0x82181830,0x82181838,0x824a93c8,0x824a953c,0x824a9540,0x824a9580,0x824a95cc,0x824a95f4,0x824a95f8"
./target/release/xenia-rs exec "../Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso" \
--halt-on-deadlock --branch-probe="$PROBE_LIST" -n 100000000 \
> audit-runs/audit-008/probe-100m.log 2> audit-runs/audit-008/probe-100m.err
```
## Constraints honored
- No code modifications (branch-probe machinery from KRNBUG-AUDIT-007 was sufficient).
- No git commit (no changes to commit).
- No backwards-compat shims.
- Probe machinery is read-only — does not perturb lockstep digest.

127
migration/claude-memory/project_xenia_rs_audit_009_renderer_unreached_2026_05_05.md Normal file
View File

@@ -0,0 +1,127 @@
---
name: KRNBUG-AUDIT-009 — renderer cluster fully unreached at -n 500M; gate is structurally above 0x82287-0x82294
description: 2026-05-05. Branch-probed all 12 audit-008-recommended PCs (6 parents + 5 shims + dispatcher) plus the AUDIT-005 9-PC producer-callsite set. 0/21 fired at -n 500M. Stop condition 1 triggered. The 0x82287000-0x82294000 cluster is not entered at all — the gate sits structurally above the cluster boundary. Diagnostic only — discipline gate fails on box 1 + 3. Next-session probe set proposed (cluster level-1 roots + new thread entry trampolines + main frame-poll callees).
type: project
originSessionId: 8822a6cd-a1c7-4484-a94f-7acd68bc35b3
---
🎯 **KRNBUG-AUDIT-009 (2026-05-05, READ-ONLY DIAGNOSTIC)** — stop condition 1 triggered. The 12 PCs proposed by AUDIT-008 + the 9 AUDIT-005 producer callsites all show `firings=0` at -n 500M. The renderer / scene-graph cluster (0x82287000-0x82294000) is fully unreached. The gate is structurally above the cluster and the discipline gate's box 1 (named import) + box 3 (sharp cascade prediction) both fail. Hand back, no code changes.
## Decisive runtime evidence (audit-runs/audit-009/probe-500m.err)
- 21 PCs armed: 6 parents (`0x82292838, 0x822878A8, 0x8228D760, 0x822900A8, 0x822919C8, 0x8228FDB8`) + 5 shims (`0x82180158, 0x821805C8, 0x82180A10, 0x82180D90, 0x821810E0`) + dispatcher `0x824AA1D8` + 9 AUDIT-005 producer-callsites (5 × 0x100c + 4 × 0x15e0 shim cluster).
- BRANCH-PROBE line count in stderr: **0**.
- Run completed at `instructions=500000010 import_calls=5629676 unimplemented=0 wall_ms=20974`.
- Final main state: `tid=1 hw=0 pc=0x822f1c60 lr=0x822f1be0 sp=0x700ff880` — inside `sub_822F1AA8` (frame-poll loop, between two `XNotifyGetNext` callsites at `0x822f1bdc` / `0x822f1c14`). LR target sits inside the same function ⇒ infinite intra-function loop.
- Counters telling the story: `XNotifyGetNext=1,489,741`, `NtWaitForSingleObjectEx=1,489,801`, `NtWaitForMultipleObjectsEx=865,493`, `RtlEnter/LeaveCriticalSection=889,109` each, `VdSwap=2`, `XAudioRegisterRenderDriverClient=1`, `XamNotifyCreateListener=1`, `XamUserGetSigninState=4`, `XamInputGetCapabilities=8`. Main is service-loop polling forever; init never proceeds past frame-poll #1.
## Thread snapshot at deadlock
| tid | hw | state | entry | ctx | parked-on |
|-----|----|-------|-------|-----|-----------|
| 1 | 0 | Ready | (main) | — | sub_822F1AA8 frame poll, PC=0x822f1c60 |
| 2 | 1 | Blocked | 0x824a93c8 (XamTaskSchedule cb) | 0x828a28f0 | handle 0x82870EBC = canary mirror |
| 3 | 5 | Blocked | 0x82181830 | **0x828F3D08** (= 0x100c) | handle 0x1020 (event) |
| 4 | 3 | Blocked | 0x8245a5d0 (cache scanner) | 0x828f4838 | handle 0x1028 |
| 5 | 3 | Blocked | 0x82450a28 | 0x828f3b68 | handles 0x104C, 0x1050 |
| 6 | 5 | Blocked | 0x82457ef0 | 0x828f3b08 | handles 0x10C4, 0x10C8 |
| 7 | 2 | Blocked | 0x824cd458 | 0x42450b3c | handle 0x42450B5C (heap, AUDIT_BLIND) |
| 8 | 4 | Ready | 0x822f1ee0 | 0x40d09a40 | — |
| 11 | 5 | Blocked | 0x82178950 | **0x828F3EC0** (= 0x1004) | handle 0x1004 |
| 14, 15 | 4 | Blocked | 0x822c6870 | 0x828f3300 | handle 0x1308 |
| 16 | 1 | Blocked | 0x824563e0 | 0x828f3e70 | handle 0x1308 |
| 17 | 4 | Blocked | 0x82170430 | **0x828F4070** (= 0x15e0) | handle 0x15F4 |
| 18 | 0 | Ready | 0x823dde30 | 0x828f3c4c | — |
| 19 | 3 | Blocked | 0x823ddb50 | 0x828f3c88 | handles 0x160C, 0x01000000 |
| 20 | 1 | Ready | 0x823ddb50 | 0x828f3c88 | — |
18 worker threads exist (incl. 0x100c worker tid=3, 0x1004 tid=11, 0x15e0 tid=17 — the three target dispatchers from the audit). All three parked, `signal_attempts=0` on lifecycle handles. The new spawn entries that didn't appear in audit-008's catalog: `0x822c6870` (×2), `0x824563e0`, `0x823dde30`, `0x823ddb50` (×2). They are likely XAM/system-event dispatchers, but unprobed.
## Canary-only export delta
Unchanged from audit-008 baseline: `{ExTerminateThread, KeReleaseSemaphore, XamUserReadProfileSettings}` (3 entries). XexCheckExecutablePrivilege fires twice (priv=10, priv=11) — confirms the post-IO-003 cascade is fully banked.
## Cluster-shape interpretation (sylpheed.db)
The 0x82287000-0x82294000 cluster is **internally cohesive but externally unreachable via direct calls**:
- The 6 parent functions (the audit-008 candidates) have only intra-cluster callers — none are called from main's call list, none are called from any function outside the 0x82287-0x82294 range.
- The cluster's level-1 roots — `sub_82293448` (only self-recursion), `sub_822919C8` (only self-recursion), `sub_82288028` (8 in-cluster callers), `sub_82292D80` (1 in-cluster caller) — have NO data/jump xrefs in sylpheed.db. They must be reached via indirect calls (vtables / function pointers), but the analysis pass didn't index those.
- Static byte-scan of `.rdata`/`.data` for the 4-byte BE encodings of these function addresses yielded 0 hits in audit-004. So the indirection is via dynamic init: the cluster's entry function-pointer is written somewhere at runtime, and we never write it.
This means the gate isn't even "main fails to call sub_82293448" — it's "main fails to populate / reach the indirect-call site that would dispatch the cluster's first job." Where that registration happens is unknown.
## Discipline gate
| # | Condition | Pass? |
|---|---|---|
| 1 | Phase 1 named a single failing kernel/xam import (α) or narrow internal-sub bug | **NO** — 0 PCs fired |
| 2 | Canary impl small (<80 LOC) | N/A |
| 3 | Sharp 4-dim cascade prediction | **NO** — no candidate fix in scope |
| 4 | No new ABI plumbing | N/A |
| 5 | Fix doesn't touch renderer subsystem | N/A |
Boxes 1 + 3 fail. **STOP. Hand back per stop condition 1.**
## Follow-up probe set for next session
Three interleaving hypotheses, one probe set:
```
PROBE_LIST=
# H1 — cluster level-1 roots: if any fires, gate is INSIDE cluster (renderer β):
0x82293448,0x822919c8,0x82288028,0x82292d80,0x822851e0,0x82286bc8,
# H2 — new thread entry trampolines (post-IO-003 spawns, unprobed):
0x822c6870,0x824563e0,0x823dde30,0x823ddb50,0x822f1ee0,
# H3 — main's frame-poll loop entry + critical PCs in its body:
0x822f1aa8,0x822f1be0,0x822f1c14,0x822f1c40,0x822f1c60,0x822f1d00,
# H4 — main's continuation (fires only if main exits frame-poll #1):
0x822f1638,0x821506b8,0x8216f088,0x82150ef8,
0x82173360,0x82173530,0x8216f170,0x824a9ad8
```
Discrimination logic:
- **All cluster roots fire + frame-poll exits** → β-class within renderer. Brief's "no renderer fixes" rule binds; document and hand back to a different person/audit.
- **Frame-poll fires but never exits** → main is stuck waiting for an XAM notification. `XamNotifyCreateListener=1` was called (the listener is registered) but `XNotifyGetNext` returns nothing actionable. Investigate which area mask was registered and which notification ID main awaits. The 1.49M loop iterations are doing nothing productive.
- **One of the new thread entries fires + advances** → that thread is the missing producer; trace its call chain into the cluster.
- **Frame-poll exits AND continuation fires** → gate is in main's post-poll sequence (sub_822F1638 etc.); narrower probe of those.
The 4-dimensional cascade prediction can only be written after this discrimination.
## Open puzzles for next session
1. **Does main's frame-poll loop EVER exit?** It looped 1.49M times in 500M instructions; exit may be at >1 billion instructions. A `--pc-probe=0x822f1aa8` with hit-count would show iteration cadence.
2. **What XAM notification does main await?** `XamNotifyCreateListener=1` registered ONE listener; the area mask + notification ID are in the call args. Capture and cross-reference against canary's listener registration.
3. **The 5 "Ready" threads (tids 8, 18, 20)** — are they actually scheduled? In lockstep mode, `Ready` threads should round-robin onto a quantum. If they accumulate Ready state without progressing, the lockstep scheduler may be skipping them — verify by adding `--branch-probe` at their entry trampolines and checking iteration counts.
4. **The 0x42450B5C heap-handle thread (tid=7, AUDIT_BLIND)** — still parked, still on a heap-pointer wait. Its source is unknown (not a kernel handle). Eligible only after the cluster fires.
5. **Single-thread variance** — between audit-008 and audit-009, tid mappings shifted (audit-008 said tid=6 was 0x15e0 worker; here it's tid=17). Spawn ordering depends on cycle counts not preserved across runs at different probe sets. Treat tid as ephemeral identifier; trust ctx (0x828F3D08 / 0x828F3EC0 / 0x828F4070) instead.
## Trace artifacts (re-runnable)
- `audit-runs/audit-009/probe-500m.log` — final state + 18-thread diag + handle audit + full counter table (22 KB).
- `audit-runs/audit-009/probe-500m.err` — full stderr trace, kernel-call log (187 KB).
- `audit-runs/audit-009/branch-probe.trace` — empty (0 BRANCH-PROBE lines emitted).
Re-run command:
```
cd "/home/fabi/RE Project Sylpheed/xenia-rs"
PROBE="0x82292838,0x822878a8,0x8228d760,0x822900a8,0x822919c8,0x8228fdb8,\
0x82180158,0x821805c8,0x82180a10,0x82180d90,0x821810e0,0x824aa1d8,\
0x821802d8,0x821806e0,0x82180b28,0x82180ea0,0x82181254,\
0x8216f9d4,0x8216fc08,0x821700b8,0x821700f4"
./target/release/xenia-rs exec sylpheed.iso \
--halt-on-deadlock --branch-probe="$PROBE" \
--trace-handles-focus=0x1004,0x100c,0x15e0,0x1020,0x10c4 \
-n 500000000 \
> audit-runs/audit-009/probe-500m.log 2> audit-runs/audit-009/probe-500m.err
```
## Constraints honored
- Stop condition 1 from the brief: 0/12 < 4/12 fired ⇒ hand back; no Phase 2 attempted.
- Discipline gate failed boxes 1 + 3 ⇒ no fix.
- No code modifications — `--branch-probe` from KRNBUG-AUDIT-007 was sufficient.
- No git commit (no source changes to commit).
- No backwards-compat shims, no speculative abstractions.
- Probe machinery is read-only — does not perturb lockstep digest.

136
migration/claude-memory/project_xenia_rs_audit_010_xnotify_diff_2026_05_05.md Normal file
View File

@@ -0,0 +1,136 @@
---
name: project_xenia_rs_audit_010_xnotify_diff_2026_05_05
description: KRNBUG-AUDIT-010 (2026-05-05, READ-ONLY) — XNotify delivery diff identifies 4 missing startup notifications gating dispatcher invocation. Branch (α). Discipline gate fails on box 3 (cannot name renderer L1 root). Diagnostic-only.
type: project
originSessionId: 330041a0-be3e-45bc-bfba-50468ea4e41c
---
# KRNBUG-AUDIT-010 — XNotify delivery diff (2026-05-05, READ-ONLY)
**Why:** First session past the kernel-boundary cascade (post-IO-003).
audit-009 left main parked in a frame-poll loop calling
`XNotifyGetNext` 1.49M times in 500M instr while the renderer cluster
remained 0/21 unreached. Per the new "delivery diff" methodology,
canary's xenia.log + canary impl files are the oracle for what
notifications should be delivered at the boot horizon vs what we
deliver.
**How to apply:** Next session must run a one-shot `--pc-probe` at
the dispatcher `bcctrl` before implementing the listener. Without
that probe, the L1-root prediction box of the discipline gate cannot
be filled.
## Branch
(α) — canary delivers 4 specific startup notifications we don't.
## Diff (decisive)
| | canary | ours |
|---|---|---|
| `XamNotifyCreateListener(0x2F, 0)` | once @ L1395 | once (audit-009 counter=1) |
| Startup notifications enqueued by `RegisterNotifyListener` | 4 (`SystemUI`, `SystemSignInChanged`, `LiveConnectionChanged`, `LiveLinkStateChanged`) | **0** (no listener registry exists) |
| `XNotifyGetNext` returns | dequeued notifications (id≠0, r3=1) | **always r3=0** (stub) |
| Calls to `XNotifyGetNext` | (canary doesn't log every call) | 1,489,741 in 500M instr |
| `XamUserReadProfileSettings` fires | yes @ L2787 (post-listener) | NO (canary-only export) |
## Root cause (kernel side)
- `crates/xenia-kernel/src/xam.rs:358-361` — `xam_notify_create_listener`
is a stub: `state.alloc_handle()`, no listener storage.
- `crates/xenia-kernel/src/xam.rs:363-366` — `xnotify_get_next` is a
stub: `ctx.gpr[3] = 0`.
- `crates/xenia-kernel/src/objects.rs:14-77` — no `NotifyListener`
variant in `KernelObject`.
- No code in `xenia-kernel` references `BroadcastNotification`,
`EnqueueNotification`, or any notification queue.
Canary reference impl:
- `kernel_state.cc:1013-1033` (`RegisterNotifyListener` + 4 startup
notifications)
- `xnotifylistener.cc:25-90` (Initialize / Enqueue / Dequeue)
- `xam_notify.cc:22-95` (XamNotifyCreateListener + XNotifyGetNext)
## Consumer side — Sylpheed dispatch
Main poll loop `sub_822F1AA8` does:
- `XNotifyGetNext(block[+132], 0, &id, &param)` (block=288-byte
alloc; listener handle at offset 132, set by `sub_822F14D8`).
- If returns 1: load `outer = mem[0x828E1F08]`, call
`outer.vtable[1](this=outer, data, id)` — drains queue in a tight
loop.
Construction:
- `sub_8216EA68` (main) → `sub_822F2758(&outer)` →
`sub_822F14D8(block, outer)`.
- `sub_822F2758:0x822f2788` sets `outer.vtable = 0x820AD894`.
- `sub_822F14D8:0x822f15c8` sets `mem[0x828E1F08] = outer`.
vtable read from `.pe` at file offset 0xAD894:
- vtable[0..3] = `0x825ED990` (looks like `__purecall`/abort:
calls debug callback at `mem[0x828A5B7C]` if non-null, then
apparent exit sequence)
- vtable[4] = `0x824C8F00` (`bclr 20, lt` — empty)
- vtable[5,6] = `0x825ED990`
- vtable[7] = `0x824C8F00`
**vtable[1] target = 0x825ED990 statically resolves to abort.**
This is suspicious — canary runs Sylpheed fine through the dispatch.
Either `mem[0x828A5B7C]` holds the real handler at runtime, or the
vtable is dynamically replaced (no such write seen in xrefs to
`mem[0x828E1F08]` beyond ctor/dtor).
## Discipline gate
| Box | | |
|---|---|---|
| 1. Specific missing notification + file:line | ✅ | 4 IDs, kernel_state.cc:1013-1033, xnotifylistener.cc:25-51, xam_notify.cc:57-95 |
| 2. <80 LOC synthesis | ✅ | ~70 LOC est. |
| 3. Sharp 4-dim cascade prediction | ❌ | Cannot name renderer L1 root |
| 4. No renderer/GPU changes | ✅ | |
**Box 3 fails → STOP, hand back. No fix landed.**
## Next session = Phase-1.5 probe + Phase-2 fix
**Step 1 (read-only probe):** temporarily patch
`xam_notify_get_next` to return one synthetic notification on first
call (e.g. id=0x0A SignInChanged, data=1). Add
`--pc-probe=0x822f1bfc,0x822f1c00`. Re-run -n 100M. Capture the
actual vtable[1] target via the bcctrl. Revert.
- target ≠ 0x825ED990 → chase real handler chain to find renderer
L1 root.
- target = 0x825ED990 → check what populates `mem[0x828A5B7C]` at
boot.
**Step 2 (fix):** Add `KernelObject::NotifyListener { mask, max_version,
is_system, queue }`. Track listeners on `KernelState`.
`xam_notify_create_listener`: build listener, on first `kXNotifySystem`-mask
auto-enqueue (0x9, IsUIActive=0)+(0xA, 1); on first `kXNotifyLive`-mask
auto-enqueue (0x02000001, 0x001510F1)+(0x02000003, 0).
`xnotify_get_next`: dequeue head (or matching-id), write outparams,
return 1/0.
## Cascade prediction (provisional)
- **Renderer L1 root**: TBD (Step 1 probe).
- **Canary-only export to fire**: `XamUserReadProfileSettings`
(canary L2787 post-listener-create).
- **signal_attempts**: renderer subsystem likely activates without
parked-handle interaction this step.
- **draws delta**: NO this step.
## Trace artifacts
`audit-runs/audit-010/findings.md` — full write-up. No code changes;
no commit. Audit-009 trace is the runtime evidence (XNotifyGetNext=1,489,741).
## Stop conditions hit
- Discipline gate box 3 fails (binding per session brief).
- Static analysis cannot resolve vtable[1] runtime target.
- Branch (α) confirmed; no need to chase β/γ paths.
## Master HEAD at session end
`50a4887` (unchanged from audit-009).

54
migration/claude-memory/project_xenia_rs_audit_012_vtable_zero_2026_05_06.md Normal file
View File

@@ -0,0 +1,54 @@
---
name: KRNBUG-AUDIT-012 vtable=0 diagnostic 2026-05-06
description: Pure runtime diagnostic that falsified ALL FIVE bug-class hypotheses for the audit-011 vtable=0 finding. Vtable IS correctly initialized; audit-011 misread runtime data. Discipline gate now PASSES for the original AUDIT-011 listener fix; next session = KRNBUG-IO-004.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-012 (2026-05-06, READ-ONLY)** — pure runtime diagnostic. Master HEAD `50a4887` unchanged. Tests 594/594. Lockstep `sylpheed_n50m` PASS.
## Probes that fired (combined 100M + 500M)
- Construction chain (100M): allocator `0x82150EF8` 8585×, outer ctor `0x8216F088` 1×, bl `0x8216F10C` 1×, inner ctor `0x822F2758` 1×, install `0x822F14D8` 1×.
- Dispatch arms (500M): `0x822F227C` 3291× / `0x822F22A4` 3291× (tid=1 main, frame chain main → 0x8216EE14 → 0x822F1E00 → 0x824BEAAC). `0x822F1D40` 1×. **All others (0x822F1B3C / 0x822F1BE8 / 0x822F1E44 / 0x822F2130 / 0x822F2200 / 0x822F2268 / 0x822F266C / 0x822F2704) fire 0×.**
- Memory transitions of `mem[0x40111890+0]`: `0x401118D0 → 0x820AD894 (cycle 5532659, sub_822F2758 wrote) → 0x820A183C (cycle 5532853, sub_8216F088 wrote)`. **Stays at 0x820A183C through end-of-run, monotonic, zero zero-transitions.**
- `mem[0x828E1F08]` (dispatcher slot): `0 → 0x40111890` at cycle 5532853, monotonic.
- `mem[0x820A183C..+12]` = real thunks `[0x82175330, 0x82175338, 0x82175340, 0x82175348]` — disasm confirms each is a `lwz r3, 8(r3); b sub_xxx` pattern to a real method.
## All five bug-class hypotheses REFUTED
| Angle | Verdict |
|-------|---------|
| 1. Atomic / store-store reorder | REFUTED — outer+0 monotonic, never flips back to 0 |
| 2. Memset/memcpy overlap | REFUTED — same evidence; no bulk-zero event |
| 3. GS-cookie / __report_gsfailure | REFUTED — no such kernel exports registered; ctor reaches normal epilogue at 0x822f27d0 |
| 4. .rdata mapping fidelity | REFUTED — vtable bytes match disasm, thunks are real |
| 5. Destructor ran by mistake | REFUTED — probes at 0x822F1638 + 0x822F16BC fire 0× in 500M; static analysis shows dtor zeroes the static slot, not outer+0 |
## Reconciliation: audit-011 misread the data
audit-011 reported `mem[0x40111890+0]=0` at PC `0x822F1BE8`. Re-reading `audit-runs/audit-011/dispatch-probe.log`: tid=1 final state shows `PC=0x8284E45C` (NOT 0x822F1BE8), `LR=0x822f1be0`. **PC `0x8284E45C` is the XAM thunk for ordinal `0x028B = XNotifyGetNext`** (xam.rs:72). The lwz at 0x822F1BE8 NEVER executes because `bc 12, 4*cr6+eq, 0x822F1C20` at 0x822f1be4 ALWAYS takes the skip arm — `xnotify_get_next` stub returns r3=0, so the "no notification" path is taken indefinitely. audit-011 captured the lwz address as the LR of the thunk return target, not as live PC.
## Reconciliation: audit-010 misattribution
audit-010's "vtable[1]=0x825ED990 abort handler" looked at the **inner ctor's transient vtable at 0x820AD894**, overwritten 3 instructions later by sub_8216F088 with the real vtable at `0x820A183C`. Real runtime vtable[1] = thunk at `0x82175338` → `sub_82173DC8` (a real method, not abort).
## Discipline gate now PASSES for KRNBUG-IO-004
1. ✅ Specific missing notification + canary file:line (kernel_state.cc:1013-1033, xam_notify.cc:22-96)
2. ✅ Synthesis < 80 LOC (~70 LOC estimate; hard ceiling 120)
3. ✅ Sharp 4-dim cascade prediction now possible
4. ✅ No renderer/GPU code changes
Predicted cascade for IO-004:
- Canary-only export `XamUserReadProfileSettings` + one of `KeReleaseSemaphore`/`ExTerminateThread` newly fire
- One of `{0x1004, 0x100c, 0x15e0}` records `signal_attempts > 0`
- audit-009 21-PC set: 1-3 newly reachable in `sub_82173DC8` ancestry
- draws delta = 0 this step (acknowledged)
Phase 1.5 sanity probe BEFORE landing IO-004: emit ONE synth notification, `--pc-probe=0x822f1c00`, expected runtime CTR = `0x82175338`. If different, vtable is dynamically replaced — abort and re-trace.
## Methodology lesson
Five static-analysis attribution failures this hunt now (audit-004 8-pool, audit-005 sub_824ABA98, audit-006 vol-info gate, audit-010 abort handler, audit-011 PC=lr confusion). Even runtime captures need careful interpretation. The combined diagnostic (PC + dump-addr + memory snapshots over time) caught what single-shot probes missed. Continue to treat all attributions as PROVISIONAL until cross-validated.
Trace artifacts: `audit-runs/audit-012/{probes-100m,dispatch-500m,handles-500m}.{log,err}`. Diagnostic patch (state.rs +11 LOC printing +0/+4/+8/+12 at every dump_addrs on every probe hit) stashed: `git stash list | grep audit-012`. Master tree clean.

92
migration/claude-memory/project_xenia_rs_audit_014_0x15e0_wake_2026_05_06.md Normal file
View File

@@ -0,0 +1,92 @@
# KRNBUG-AUDIT-014 — 0x15e0 wake hypothesis FALSIFIED (2026-05-06)
## Status
READ-ONLY DIAGNOSTIC. No fix landed. Master HEAD `d736a1d` unchanged. Tests
remain at 599. Lockstep instructions=100000012 (pre-existing IO-004
baseline).
## Goal
Investigate why handle 0x15e0 records `signal_attempts=1 (primary=1)`
post-IO-004 BUT tid=17 (the audit-009 stage-3 "0x15e0 worker") is still
parked. If a narrow fix-shape gap (wake-eligibility / shadow / mr /
ordering) was found, land it inline. Otherwise diagnostic-only.
## Phase 1 finding (decisive — premise refuted)
Trace at `-n 500M --trace-handles-focus=0x15e0` decisively shows:
1. **0x15e0 is a Semaphore, not an Event**. Created via `NtCreateSemaphore`
at `lr=0x824ab110` on tid=1. Creator-frame chain
`0x82456a94 → 0x82456bac → 0x822f1b60 → 0x8216ee14 → 0x824ab8e0` —
**distinct** from the Event creator chain `lr=0x824a9f6c` shared by
0x1004 / 0x100c / 0x1020 / 0x15e4.
2. **0x15e0 is healthy**: `signal_attempts=1 (primary=1) waits=1 wakes=1`.
Timeline: tid=1 wait at `lr=0x824ac578`, then tid=16 `NtReleaseSemaphore`
at `lr=0x824ab168` woke it. End-of-run DIAGNOSIS: "not stuck — signals
consumed correctly".
3. **tid=17 parks on 0x15e4**, NOT 0x15e0. End-of-run state:
`Blocked(WaitAny { handles: [5604] })` where `5604 == 0x15e4`. Worker
`r12=0x8217057c` (front of `sub_82170430`), matching the audit-009 /
audit-008 / audit-002 stage-3 worker mapping for tid=17.
4. **0x15e4 is the actually-stuck handle**: `Event/Manual waiters=1
signals=0 waits=1 wakes=0 <NO_SIGNALS_DESPITE_WAITS>`. Same producer-
missing class as 0x1004 / 0x100c / 0x1020.
The IO-004 cascade-prediction line "(e) signal_attempts on parked handles:
0x15e0 = 1 (primary=1, ghost=0)" was correct but mis-interpreted: the
semaphore did receive one signal, but it was unrelated to tid=17's wake.
## Long-standing label error
The string "0x15e0 worker" appears in audit-002 (producer stack trace),
audit-008 (β-class gate), audit-009 (stage-3 thread-state map) and the
IO-004 prediction. The actual handle is 0x15e4 (Event/Manual). The
audit-002 memory entry already had a note "third handle is **0x15e0**,
not 0x15e4 (transcription typo)" — that correction was itself reversed:
the original audit-002 label of 0x15e4 was correct.
## Bug class evaluation (α-ζ per prompt)
| Class | Verdict |
|---|---|
| α PKEVENT vs handle mismatch | N/A — no Set call ever targets 0x15e4 |
| β refresh_pkevent_shadow miss | N/A |
| γ wake-eligibility filter wrong | N/A — manual-reset wake works elsewhere (0x10F0 handshake; 0x15e0 semaphore wake) |
| δ memory ordering | N/A — no producer side ever runs |
| ε race scheduler.resume vs signal | N/A |
| ζ audit recorded but not propagated | N/A — diagnosis matches state.objects waiter list |
**Producer for 0x15e4 is genuinely missing**, same class as 0x1004 /
0x100c / 0x1020. No wake-eligibility bug.
## Discipline gate
- Box 1 (named bug class with evidence): **FAIL** — premise refuted.
- Box 2 (~30-80 LOC fix): N/A.
- Box 3 (4-dim cascade prediction): N/A.
- Box 4 (no renderer/GPU changes): N/A.
- Box 5 (lockstep determinism preserved): N/A.
Stop condition met: hand back, no fix.
## Cascade snapshot (unchanged from IO-004)
- swaps=2 (VdSwap frames 1+2 kernel-direct)
- draws=0
- 18 → 20 worker threads, identical to IO-004
- Canary-only exports unchanged: `ExTerminateThread`, `KeReleaseSemaphore`,
`XamUserReadProfileSettings`.
## Recommended next session
Use Fork B's branch-probe results on the newly-reached renderer L1 entries
`sub_82173DC8 / 0x822c6870 / 0x824563e0 / 0x823ddb50`. The producer for
0x1004 / 0x100c / 0x1020 / 0x15e4 lives somewhere along the dispatch arm
`0x822f1be8 → 0x82175338 → 0x82173dc8 → ...`. If a sub-function gates the
Set call on a stub kernel export return value, that becomes
KRNBUG-AUDIT-015 / IO-NNN candidate.
A secondary cleanup pass should rewrite the "0x15e0 worker" labels to
"0x15e4 worker" across the AUDIT-002 / AUDIT-008 / AUDIT-009 / IO-004
memory entries.
## Trace artifacts
- `xenia-rs/audit-runs/audit-014-0x15e0-wake/probe.log` — focus dump,
19-thread state diagnostic, full handle audit table.
- `xenia-rs/audit-runs/audit-014-0x15e0-wake/probe.err` — kernel.calls
counters confirming swaps=2 / VdSwap=2 baseline unchanged.

178
migration/claude-memory/project_xenia_rs_audit_015_l1_propagation_2026_05_06.md Normal file
View File

@@ -0,0 +1,178 @@
---
name: KRNBUG-AUDIT-015 — L1 propagation probe; next gate is silph::Semaphore on handle 0x1308 (workitem submitter never invoked)
description: 2026-05-06. Read-only branch-probe of the 4 newly-reached renderer L1 entries (sub_82173DC8 + workers 0x822c6870 / 0x824563e0 / 0x823ddb50) at -n 500M post-IO-004. 28/112 PCs fired, decisively bounding the next gate. sub_82173DC8 dispatches all 4 startup notifications then idles. Two of the three "newly-reached" workers (tid=14, tid=15 on 0x822c6870 → sub_822c6878) park on Semaphore handle 0x1308 with signal_attempts=0; their producer chain is sub_822AE1F0 / sub_822F55F0 → sub_822C8B50 → sub_822C6808 (silph::Semaphore::Release wrapper) — neither caller fires in this run, so the workitem-submission entry is the next gate. Worker tid=16 (0x824563e0) actually progresses through its dispatch loop and parks on a Timer/CS-cycle. Tid=19 (0x823ddb50) parks at entry. Bug class is δ (pure-guest renderer state-read), not a kernel-boundary stub. No fix.
type: project
originSessionId: fork-b-2026-05-06
---
🎯 **KRNBUG-AUDIT-015 (2026-05-06, READ-ONLY DIAGNOSTIC, FORK B)** — branch-probed 112 PCs across the 4 renderer L1 entry trampolines and their callees. 28 fired, 84 unfired. The next gate is **Semaphore handle 0x1308** (`signals=0 waits=2`) waited on by the `sub_822c6878` worker pool — its producer chain `sub_822AE1F0 / sub_822F55F0 → sub_822C8B50 → sub_822C6808 (→ silph::Semaphore::Release at 0x824AB158)` is structurally unreached. Bug-class **δ (pure-guest renderer)**: no kernel boundary stub, no missing import — it is a workitem-submission path that main never invokes. Stop condition 1 satisfied (no narrow fix in scope this session). Master HEAD `d736a1d` unchanged. Sister Fork A on AUDIT-014 (0x15e0/0x15e4 wake) untouched.
## Probe set used (112 PCs)
- **sub_82173DC8 dispatcher**: entry + 25 case-arm/branch-target PCs (all 5 case bodies + the post-merge dispatch helper bl 0x82174040).
- **worker 0x822c6878** (= 0x822c6870 thunk target): entry + 11 body PCs covering wait, queue scan, CS lock, vtable[1] dispatch (`bcctrl` at 0x822c6974), signal-completion `NtSetEvent`.
- **worker sub_824563E0**: entry + 16 body PCs covering all `bl` and both `bcctrl` sites.
- **worker sub_823DDB50**: entry + 10 body PCs.
- **L1 callees** (silph wrappers + renderer subs): 26 PCs.
- **audit-009 originally-unfired set** (renderer cluster + audit-005 producers): 21 PCs (preserved as control).
Full list: see `audit-runs/audit-015-l1-propagation/probe.log` first 1KB or memory file source.
## Per-probe fire/no-fire (28 fired)
| Group | PC | Hits | Notes |
|---|---|---|---|
| dispatcher | 0x82173dc8 | 4 | tid=1 only; r3=0x40ba9a80 (= sylpheed listener struct) |
| dispatcher | 0x82173dec | 2 | case-discriminator |
| dispatcher | 0x82173dfc | 1 | case 0xA arm body (notification 0x0A=LiveConnectionChanged) |
| dispatcher | 0x82173e40 | 1 | case 0x9 arm body (notification 0x09=SystemSignInChanged) |
| dispatcher | 0x82173e6c | 1 | case 9 atomic-CAS arm |
| dispatcher | 0x82173ed0 | 1 | post-arm convergence (r11=44(r31)==0 → exit) |
| dispatcher | 0x82173f48 | 2 | default-high arm (notification id > 0xB twice) |
| dispatcher | 0x82174030 | 3 | default exit (early) |
| dispatcher | 0x821737f0 | 2 | bl from case 9 (silph helper) |
| dispatcher | 0x822c2a80 | 1 | renderer profile-loader, tid=1, lr=0x822c28d4 (cycle 9186021) |
| dispatcher | 0x82181c28 | 1 | tid=1, lr=0x8216eaa4 (silph init helper) |
| dispatcher | 0x821707c0 | 4 | early-init helper |
| dispatcher | 0x8216f088 | 1 | tid=1 |
| dispatcher | 0x8216f798 | 1 | tid=1 |
| worker entry | 0x822c6878 | 2 | tid=14, tid=15 thread-start (lr=0xbcbcbcbc) — body PCs UNFIRED |
| worker entry | 0x824563e0 | 1 | tid=16 thread-start; loops in body |
| worker entry | 0x823ddb50 | 1 | tid=19 thread-start; body UNFIRED |
| L1 callee | 0x82456420 | 1 | tid=16 only (called once from 0x824563E0+0x24) |
| L1 callee | 0x82456530 | 865,112 | tid=16 dispatch-cycle hot-spot |
| L1 callee | 0x824568d8 | 1 | tid=16 only |
| L1 callee | 0x82334ca0 | 555 | renderer; tid=16 |
| L1 callee | 0x8244e218 | 1664 | tid=16 |
| L1 callee | 0x82612788 | 1 | NtSetTimerEx (handle 0x15d0); tid=16 cycle=70 |
| L1 callee | 0x82611cd8 | 1,825,719 | hot trivial getter (lwz lwz blr); tid=1+8 |
| silph | 0x824aa658 | 12 | obref helper (handles 0x130c, 0x1310, etc.) |
| silph | 0x824aa330 | 1,489,799 | wait wrapper; 1.49M from main lr=0x822f1e00 |
| silph | 0x824aa2f0 | 3334 | NtSetEvent wrapper |
| silph | 0x824ab240 | 865,494 | XamEnableInactivityProcessing wrapper; tid=16 inner-loop |
**84 unfired**, including all 21 original audit-009 PCs (renderer cluster `0x82287xxx-0x82294xxx` and audit-005 producer callsites) plus the body PCs of worker 0x822c6878 (0x822c6894 / 68a4 / 68c8 / 68cc / 6960 / 6964 / 6974 / 697c / 69a0 / 69b4 — all 0 hits) and the body PCs of 0x823ddb50 (0x823ddb68 / bbe0 / bbf8 / bc14 / bc64 / bc78 / bcbc / bcc4 / bce0 / bcf4 — all 0 hits).
## Per-question answers
**Q1 — Does sub_82173DC8 enter all callees, or early-exit?**
Early-exit. The dispatcher fires 4 times (matching the 4 startup notifications enqueued by IO-004 — case 0x9, case 0xA, and twice on default-high for `0x02000001` / `0x02000003`). For each fire the post-arm code at 0x82173ed0 reads `r11 = 44(r31)` and **branches to 0x82174030 (early exit) when r11==0**. Field `[r31+44]` is a "callback table pointer" in the listener struct that Sylpheed never populates (= NULL). The dispatch helper at 0x82174040 (which calls `sub_822C2A80`, `sub_8216F088`, `sub_82181C28`, etc.) is never invoked from the dispatcher path. The single 0x822c2a80 fire came from a separate caller (lr=0x822c28d4, in `sub_822C27F0` — orthogonal renderer init). The 4 dispatch fires drain the listener queue once and the dispatcher is silent for the remaining 1.49M XNotifyGetNext calls.
**Q2 — Worker 0x822c6870 (tids 14, 15) progress?**
Parks immediately. Both threads enter `sub_822c6878`, immediately call `bl 0x824AA330` at 0x822c6894 (= `silph::Semaphore::Wait` on handle 0x1308 in r3, with infinite timeout). Handle 0x1308 is a `Semaphore(0/INT_MAX)` with `signals=0 waits=2 wakes=0 <NO_SIGNALS_DESPITE_WAITS>`. Created by tid=13 at `lr=0x824ab110` (NtCreateSemaphore wrapper called from `sub_822C66B4` inside `sub_822C6630`, the worker-pool initializer reached from `sub_822C6A40`). Producers: only `sub_822C6808` releases it (`bl 0x824AB158` at 0x822c6848). `sub_822C6808` has a single caller chain `sub_822C8B50` (the workitem-submitter) which is itself called from `sub_822AE1F0` (at 0x822b16e0) or `sub_822F55F0` (at 0x822f5728). **Neither sub_822AE1F0 nor sub_822F55F0 was probed; both are statically reachable from main but not exercised in this 500M run** — they're the renderer's frame-update or scene-graph mutate path which Sylpheed gates on something main has not yet completed.
**Q3 — Worker sub_824563E0 (tid=16)?**
**Progresses** through one full pass and enters a steady-state inner loop. Trace at cycle 0-1500:
1. `bl 0x824AA658` (ObReferenceObjectByHandle helper, r3=-2 = self)
2. `bl 0x82456420` (sub-init)
3. `bl 0x82612788` (NtSetTimerEx, r3=0x15d0 — timer handle, period=2)
4. `bl 0x824AB240` → `bl __imp_xam.xex_XamEnableInactivityProcessing(2)` (returns 0)
5. `bl 0x82456530` (CS-locked vtable[0]/[+0x4] dispatch via `bcctrl` at 0x8245655c — fires 865k times)
6. `bl 0x824568D8` (handle slot lookup)
7. `bl 0x82334CA0` (renderer; large 1056-byte fn — fires 555 times)
8. `bl 0x8244E218` (linked-list scanner — fires 1664 times)
9. Then loops {0x824ab240 (XamEnableInactivityProcessing) ↔ 0x82456530 (CS+bcctrl dispatch)} forever
- `0x82456530`: 865,112 fires; `0x824ab240`: 865,494 fires
- This is a poll loop. The bcctrl target inside 0x82456530 (read from `[r29+0]` at offset 4) doesn't advance any state main is waiting for.
Tid=16 is **not the gate** — it's a healthy timer-driven inactivity-poll loop, doing what canary's equivalent does. Probably an XAM heartbeat thread.
**Q4 — Worker sub_823DDB50 (tid=19)?**
Parks at entry. Entry fires once at thread-start (lr=0xbcbcbcbc), but every body PC (0x823ddb68 onward) is unfired. End-of-run state: `Blocked(WaitAny { handles: [5644, 16777216] })` = `[0x160C, 0x01000000]`. Handle 0x160C is `Event/Auto signals=0 waits=1 wakes=0 <NO_SIGNALS_DESPITE_WAITS>`; the second value 0x01000000 = INFINITE timeout. The wait must occur via a path that bypasses the probed body — likely the very first instruction at 0x823ddb50 (`mfspr r12, LR`) is followed by an out-of-probe-range early bail. Look at `sub_823DDB50` instructions 0..0x10 (entry didn't show body fire because the wait happens via `bl 0x82611CD8` at 0x823ddb68 — wait, but 0x823ddb68 is unfired). The actual wait callsite is unprobed; tid=19's lr at deadlock is `0x824ab214` (= silph wait wrapper inner). **Most likely tid=19 entered a different sub_823DDB50 sibling function via a tail-call, OR the body PCs are reached at slightly different offsets than the disasm shows**. Worth a follow-up probe with PCs in `sub_823DD838` (the parent, where 0x823ddb50 is referenced as data at 0x823dd918).
**Q5 — New imports/exports being called we hadn't seen fire?**
Compared to audit-009 baseline (`ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings` were canary-only), this run's counter table shows the same 3 still canary-only. New kernel calls fired post-IO-004:
- `NtCreateTimer = 1` (was 0; tid=16 timer creation for handle 0x15d0)
- `NtSetTimerEx = 1` (was 0)
- `XAudioRegisterRenderDriverClient = 1`
- `XamInputGetCapabilities = 8`
- `XamUserGetSigninState = 4`
- `XamUserGetXUID = 1` (NEW — was unprobed)
- `XNotifyPositionUI = 1` (NEW)
No NEW canary-only-divergence relative to IO-004's accounting.
## Next-gate hypothesis + classification
**Class: δ (pure-guest renderer state-read)** — the gate is structurally inside the guest's frame-update / scene-graph submission path, NOT a kernel-boundary stub.
**Hypothesis**: main is supposed to call `sub_822AE1F0` or `sub_822F55F0` once init advances past the 4 startup notifications + the singleton renderer-profile load (`sub_822C2A80` already fired once). Those functions in turn call `sub_822C8B50 → sub_822C6808`, which posts work to handle 0x1308 (the sub_822c6878 worker pool semaphore). Until that posts, tids 14 + 15 sleep on `signals=0`.
The triggering mechanism is the dispatcher arm at `0x82173ed0`: when it observes `r11 = 44(r31) != 0` it would fall through to the post-merge handler (one of `0x82174018`, the dispatch helper at `0x82174040`, etc.). Right now `[r31+44] == 0` for all 4 dispatch fires. The field is set somewhere — but only by guest code we never reach.
Cross-reference vs. canary log: canary's `xenia.log` shows the same dispatcher path with `[r31+44]` populated and the post-merge handler firing, leading to the renderer-job submitter cascade. The entry that populates `[r31+44]` is plausibly the same `sub_822C2A80` pathway, but a different LR-context (canary's call comes from sub_82174040, not from sub_822c28d4 as in our run).
**File:line evidence**:
- `sub_82173DC8` dispatcher early-exit at `0x82173ed8 (bc beq cr6, 0x82174030)` — gate predicate is `[r31+44] == 0`. Disasm: `xenia-rs/sylpheed.db` instructions table for PCs 0x82173ed0-0x82173ee8.
- Workitem submitter `sub_822C8B50` at 0x822c8bb0 (`bl 0x822C6808`) is the only path to release Semaphore 0x1308. Caller: `sub_822AE1F0:0x822b16e0` or `sub_822F55F0:0x822f5728`.
- Semaphore creator: `sub_822C66B4 (bl sub_824AB110)` inside `sub_822C6630`, called from `sub_822C6A40` (the only caller).
## Recommended next-session target
Phase 1 of the next session should:
1. **Probe `sub_822AE1F0`, `sub_822F55F0`, `sub_822C8B50`, `sub_822C6808` entry PCs** at `-n 500M`. If any fires, the gate is even further upstream (a producer of the producer); if 0/4 fire, the gate is on an even earlier path that calls one of these.
2. **Probe `sub_82173DC8` post-merge dispatch helper at 0x82174040 entry, plus the 6 fall-through arms (0x82174018, 0x82173EF8, 0x82173E60, 0x82173FE4, 0x82173F70, 0x82173F44)** — see whether the 4 fired notifications are filtered out (their `[r31+44] == 0` may be a property of all 4 startup notifications; canary's `[r31+44]` is only non-zero for non-startup notifications).
3. **Dump the listener struct at runtime** with `--dump-addr=0x40ba9a80` (the r3 value seen at the dispatcher fires). This reveals what fields are populated at +44, +60 (`r11 = 60(r28)` in default arm), +64, etc.
**No discipline-gate-passing fix this session.** Box 1 (named import α-class bug) FAILS — there is no missing kernel/xam stub at the gate; box 3 (sharp 4-dim cascade) cannot be sharpened without the dump-addr trace.
If forced to pick a "fix candidate" for the next session, the highest-information probe is **dump-addr 0x40ba9a80** under `--branch-probe=0x82173ed0` to see the listener struct each time the dispatcher discriminates. That bypasses guesswork about which path canary takes.
## Discipline gate
| # | Condition | Pass? |
|---|---|---|
| 1 | Phase 1 named a single failing kernel/xam import (α) or narrow internal-sub bug | **NO** — gate is δ-class (pure-guest), no kernel boundary |
| 2 | Canary impl small (<80 LOC) | N/A |
| 3 | Sharp 4-dim cascade prediction | **NO** — needs dump-addr triage first |
| 4 | No new ABI plumbing | N/A |
| 5 | Fix doesn't touch renderer subsystem | N/A |
Boxes 1 + 3 fail. **STOP. Hand back per stop condition 1.** No fix attempted, no commit.
## Cascade snapshot (unchanged from IO-004)
- swaps=2, draws=0
- 20 worker threads
- VdSwap=2, instructions=500M completed
- Canary-only exports unchanged: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`
- New still-stuck handles: 0x1308 (Semaphore, 2 waiters), 0x15d0 (Timer, 32 waits 0 wakes — owned by tid=16's poll loop, EXPECTED), 0x15d4 (Event/Auto, 32/0)
## Trace artifacts (re-runnable)
- `audit-runs/audit-015-l1-propagation/probe.log` (493 MB; 5.05M BRANCH-PROBE lines; final state + 20-thread diag + handle audit + counter table)
- `audit-runs/audit-015-l1-propagation/probe.err` (188 KB; stderr / structured events)
- `audit-runs/audit-015-l1-propagation/pc-fire-counts.txt` (28 fired PCs sorted by hit count; aggregate of probe.log via `awk | sort | uniq -c`)
Re-run command:
```
PROBE="0x8216f088,0x8216f170,0x8216f798,0x8216f9d4,0x8216fc08,0x821700b8,0x821700f4,\
0x821707c0,0x82173108,0x821737f0,0x82173dc8,0x82173dec,0x82173dfc,0x82173e40,\
0x82173e6c,0x82173eb0,0x82173ec4,0x82173ed0,0x82173ef8,0x82173f00,0x82173f2c,\
0x82173f48,0x82173f70,0x82173f74,0x82173f90,0x82174018,0x82174030,0x82174040,\
0x8217405c,0x821740a0,0x821740e4,0x821740ec,0x821740f8,0x82174104,0x8217410c,\
0x821752c0,0x8217da30,0x82180158,0x821802d8,0x821805c8,0x821806e0,0x82180a10,\
0x82180b28,0x82180d90,0x82180ea0,0x821810e0,0x82181254,0x82181c28,0x82181ca8,\
0x82181d48,0x822878a8,0x8228d760,0x8228fdb8,0x822900a8,0x822919c8,0x82292838,\
0x822c2a80,0x822c6878,0x822c6894,0x822c68a4,0x822c68c8,0x822c68cc,0x822c6960,\
0x822c6964,0x822c6974,0x822c697c,0x822c69a0,0x822c69b4,0x82334ca0,0x823ddb50,\
0x823ddb68,0x823ddbe0,0x823ddbf8,0x823ddc14,0x823ddc64,0x823ddc78,0x823ddcbc,\
0x823ddcc4,0x823ddce0,0x823ddcf4,0x8244e218,0x824563e0,0x824563fc,0x82456404,\
0x82456420,0x82456444,0x82456458,0x8245647c,0x824564bc,0x824564cc,0x824564f8,\
0x82456530,0x82456534,0x8245655c,0x824565b0,0x824565cc,0x824565ec,0x82456600,\
0x8245660c,0x82456638,0x824567e0,0x824568d8,0x824aa1d8,0x824aa2f0,0x824aa330,\
0x824aa350,0x824aa658,0x824aa848,0x824ab240,0x82611cd8,0x82612788,0x826127f0"
./target/release/xenia-rs exec sylpheed.iso \
--halt-on-deadlock --branch-probe="$PROBE" \
--trace-handles-focus=0x1004,0x100c,0x15e0,0x1020,0x10c4 \
-n 500000000 \
> audit-runs/audit-015-l1-propagation/probe.log 2> audit-runs/audit-015-l1-propagation/probe.err
```
## Constraints honored
- Stop condition 1: 28/112 fired bounds the gate but doesn't yield a narrow fix. Hand back.
- Discipline gate failed boxes 1 + 3 ⇒ no fix.
- No code modifications — `--branch-probe` from KRNBUG-AUDIT-007 was sufficient.
- No git commit (no source changes; memory file + audit-findings.md update is documentation only).
- Sister Fork A on AUDIT-014 / 0x15e0 wake untouched — Set/wait/audit code paths and 0x15e0 handle mechanics not visited.
- C++ runtime audit backlog (CPPBUG-AUDIT-001) not visited.
- No new ABI plumbing.
- No git push.

137
migration/claude-memory/project_xenia_rs_audit_016_submitter_callers_2026_05_06.md Normal file
View File

@@ -0,0 +1,137 @@
---
name: KRNBUG-AUDIT-016 — submitter-caller probe; gate is deeper-indirection γ (workitem submitter chain unreachable via vtable registry not populated by guest renderer init)
description: 2026-05-06. Read-only branch-probe at -n 500M of the workitem-submitter chain `sub_822AE1F0` / `sub_822F55F0` (and parents/grandparents) plus `sub_82173DC8` dispatcher arms, with `--dump-addr=0x40ba9a80` of the listener struct. **0/16 fire on any submitter-chain PC** including 4 levels of caller walk-up. The chain bottom-outs in the audit-009 renderer cluster (`0x82287xxx-0x82294xxx`) which has zero non-call xrefs — vtable-dispatched targets stored in a registry that's never populated. Listener struct dump shows `[base+0x2C] = 0x4024AC00` (callback-table pointer IS populated; audit-015's "==0" claim was wrong); `[base+0x04] = 0` (dispatch state bits NEVER set); the actual gate is `sub_821737F0`'s predicate evaluation reading bit 14 of [base+4]. Bug class **γ (deeper indirection)** not δ. Master HEAD `d736a1d` unchanged. No fix.
type: project
originSessionId: audit-016-2026-05-06
---
🎯 **KRNBUG-AUDIT-016 (2026-05-06, READ-ONLY DIAGNOSTIC)** — branch-probed 30 PCs across the workitem-submitter chain (`sub_822AE1F0`, `sub_822F55F0`, `sub_822C8B50`, `sub_822C6808`, including bl-call-sites at `0x822B16E0` / `0x822F5728`) and 4 levels of caller walk-up: parents (`sub_822ADD70`, `sub_821A9920`, `sub_822ACAB8`, `sub_821A8578`), grandparents (`sub_82299250`, `sub_822A4460`, `sub_821A82A0`), great-grandparents (`sub_8229AB50`, `sub_822A5C10`, `sub_821AC700`), at `-n 500M`. **0/16 submitter-chain PCs fire**. Followup probe of dispatcher arms (sub_82173DC8 case 9 / case 0xB / default-high) + `--dump-addr=0x40ba9a80` reveals the listener struct is **partially populated** but `[base+0x04]` (dispatch state bits) stays zero across all 4 startup notification dispatches → `sub_821737F0` returns 0 → all dispatch arms early-exit at `0x82174030`. Gate class is **γ (deeper indirection)** — the submitter-chain entry-point is in a registry-dispatched cluster (the audit-009 renderer cluster `0x82287xxx-0x82294xxx`) that's never reached. No fix attempted.
## Probe set used
**Run #1** (30 PCs): Tier 1 (workitem chain entries + bl sites), Tier 2 (parents + bl sites), Tier 2.5 (grandparents), Tier 3 (sub_82173DC8 post-merge dispatch helper + early-exit `0x82174030`).
**Run #2** (18 PCs): refined dispatcher arm coverage (case 9 atomic-CAS arm, default-high arms, helpers `sub_82181C28` / `sub_82181D48` / `sub_821737F0` / `sub_82174040`) + `--dump-addr=0x40ba9a80,0x4024AC00,0x4024B3E0,0x40111890,0x4024A380` to trace the listener and its referenced sub-objects.
## Per-probe fire/no-fire (combined: 11+10 fires = 21 events)
| Group | PC | Fires | Notes |
|---|---|---|---|
| dispatcher entry | 0x82173dc8 | 4 | tid=1, r3=0x40ba9a80, lr=0x822f1c04 (frame-poll caller) |
| dispatcher trampoline | 0x82175338 | 4 | tid=1 (the 4 startup notifications from IO-004) |
| dispatcher arm | 0x82173e6c | 1 | case-9 r5==0 atomic CAS arm |
| dispatcher arm | 0x82173eac | 1 | pre-bl `mr r3, r31; bl 0x821737F0` |
| dispatcher arm | 0x82173f48 | 2 | case-0xB / default-high (r11>0xB) — fired twice |
| sub_821737F0 | 0x821737F0 | 2 | (a) lr=0x82173eb4 from case 9 — returned 0 → early-exit; (b) lr=0x821741f4 from INSIDE sub_82174040 mid-body — confirms helper IS reached eventually but caller of sub_82174040 itself unprobed |
| early-exit | 0x82174030 | 3 | once from case 9 (lr=0x82173eb4), twice from default-high (lr=0x82173dd0) |
| renderer-init | 0x82181c28 | 1 | cycle 5378618, lr=0x8216eaa4 — orthogonal early-init listener-getter call (same as audit-015) |
| **Tier 1 (workitem chain)** | 0x822AE1F0, 0x822F55F0, 0x822C8B50, 0x822C6808, 0x822B16E0, 0x822F5728 | **0** | UNFIRED — entire workitem submitter chain |
| **Tier 2 (parents)** | 0x822ADD70, 0x821A9920, 0x822ACAB8, 0x821A8578 + bl sites 0x822AE12C, 0x822ACB54, 0x822ACB88, 0x821A98FC, 0x821AB1C0 | **0** | UNFIRED |
| **Tier 2.5 (grandparents)** | 0x82299250, 0x822A4460, 0x821A82A0, 0x82299724, 0x822A49B8, 0x821A8464 | **0** | UNFIRED |
| dispatcher post-merge | 0x82174040, 0x82174018, 0x8217401C, 0x82173EF8, 0x82173EC4, 0x82173EBC | **0** | UNFIRED at function-entry granularity (yet `sub_821737F0` is called from 0x821741F4 mid-body — implies entry probe missed it; possible probe-machinery gap, see anomalies below) |
## Listener struct snapshot (`[0x40ba9a80]`, EOR after 4 dispatches)
```
+0x00: 40 11 18 90 — vtable pointer (= 0x40111890; vtable[0]=0x820A183C, [+0x4]=0x40D09A40, [+0x8]=0x40BA9A80 (self), [+0x10]=0x405422C0)
+0x04: 00 00 00 00 — dispatch state bits (NEVER SET despite 4 dispatches; this IS the gate)
+0x08: 00 00 00 00 — atomic counter (zeroed by case-9 r5==0 CAS)
+0x0C: 00 00 03 e8 — = 1000 (set by case 0xA: subfic r11, r11, 1000)
+0x10: 01 00 00 00 — flag
+0x20: ff ff ff ff — sentinel
+0x2C: 40 24 ac 00 — **CALLBACK-TABLE PTR A (POPULATED!)** — points to {[+0]=0x401119A0, [+0x4]=0x40111990, [+0xC]=0xFFFFFFFF, [+0x40]="game:\\dat\\GP_TITLE.pak+eng\\\0"}
+0x3C: 40 24 b3 e0 — **CALLBACK-TABLE PTR B (POPULATED!)** — secondary callback table
+0x40: 00 00 00 08 / 0000001f / 00000001 / 41d7f398
+0x50: 40 24 a3 80 — file-list pointer
```
**Audit-015's claim that `[r31+44]==0` is WRONG.** `[r31+44]` = `[base+0x2C]` = `0x4024AC00` (NON-zero). The gate is not `[+0x2C]==0`; it's `[+0x04]` (dispatch state bits). The dispatcher's case-9 path goes through `sub_821737F0` which checks `[base+4]` bit 14 and bit 15 — both are 0 → falls through deeper logic that returns 0 → case-9 early-exits. The default-high path (case 0xB) calls `bl 0x82181C28` whose return is then checked: `[[r3+0]+0] != -1` and `bl 0x82181D48` returning 1; one of those gates fails too.
Per the **0x4024AC00 dump (= callback table A)**: it contains a real game-asset string "game:\\dat\\GP_TITLE.pak+eng\\" — confirming the listener subscription HAS been initialized to point at the renderer's config tree. The renderer init fires this much. What it doesn't do is set the dispatch-state bits in `[base+0x04]`.
## Per-question answers
**Q1 — Which Tier 1 functions fire?** None. `sub_822AE1F0`, `sub_822F55F0`, `sub_822C8B50`, `sub_822C6808`, the bl call-sites `0x822B16E0` / `0x822F5728` — all 0 fires.
**Q2 — Which Tier 2 / 2.5 callers fire?** None. The static caller chain is `sub_822AE1F0 ← sub_822ADD70 (sub_822ACAB8 +0x9C / +0xD0) ← sub_82299250 / sub_822A4460 ← sub_8229AB50 / sub_822A5C10 ← sub_8229A700 / sub_822A5AE8 ← sub_82294F30 / sub_822A1438` — bottoming out in the **audit-009 renderer cluster** `0x82294xxx`. None of these fire. For sub_822F55F0: `sub_822F55F0 ← sub_821A9920 ← sub_821A8578 ← sub_821A82A0 ← (recursive cycle with sub_821A9920) and ← sub_821ABEA8 ← sub_821AC700 ← sub_821A6470 / sub_821A6C68 / sub_821AC580` — also bottoming in the renderer cluster `0x821A6xxx`. None fire.
**Q3 — Listener struct field-population state at 0x40ba9a80?** Partially populated. Vtable + 2 callback-table pointers (`[+0x2C]=0x4024AC00`, `[+0x3C]=0x4024B3E0`) + asset paths are set. **`[+0x04]` (dispatch state bits) stays 0 across all 4 dispatcher fires** — case-0xA's `oris 0x1; stw [r31+4]` should set bit 16, but the dump shows 0. This means either case 0xA's write doesn't persist to this struct (different r31?) OR the dispatch happens with r3 pointing to a DIFFERENT struct than 0x40ba9a80 in some fires. Most likely the dispatcher is invoked once by the trampoline (0x82175338 lr=0x822f1c04) but the per-notification dispatch fans out to internal dispatch ops that don't always target 0x40ba9a80.
**Q4 — Cross-reference vs canary's xenia.log?** Canary log at `/home/fabi/xenia_canary_windows/xenia.log` only logs `XNotifyGetNext` import binding (no per-call detail). No useful cross-ref at the dispatcher layer.
**Q5 — Specific notification missing or wrong?** The 4 startup notifications (per audit-015: 0x09, 0x0A, 0x02000001, 0x02000003) ARE delivered and the dispatcher arms ARE entered (case 9 + case 0xA + 2× default-high). But every arm hits an early-exit because the listener struct's dispatch state bits / sub_821737F0 deeper-predicate / case-0xB's `bl 0x82181D48` predicate all return 0. **The notifications are not missing; the listener's INTERNAL state never advances out of its initial config-load phase.** That state advance is what `sub_822AE1F0` / `sub_822F55F0` are supposed to do via the workitem-submitter chain — but they're never invoked because their callers in the renderer cluster are themselves never invoked.
## Bug class classification: **γ (deeper indirection)**
Earlier audits classified this as δ (pure-guest renderer state-read). The new finding refines this to γ:
- The workitem submitter chain (`sub_822AE1F0` / `sub_822F55F0` → `sub_822C8B50` → `sub_822C6808`) is reached only via parents in the renderer cluster.
- The renderer cluster (`0x82287000-0x82294FFF` + `0x821A6xxx-0x821ABxxx`) per audit-009 has **zero non-call xrefs** to its L1 entry-points — it's vtable-dispatched from a registry that's never populated.
- The registry population is what main is supposed to drive via the listener dispatch — but the listener dispatch early-exits because the *listener's own state* is never advanced.
It's a **chicken-and-egg loop**: listener can't advance state because workitem-submitter never fires; workitem-submitter never fires because the registry it lives in is never populated; the registry is populated by something the listener is supposed to drive. Only an external bootstrap can break it. That bootstrap is the **renderer's master init function** — likely an unprobed L1 entry like `sub_822F1AA8` (the main frame-poll loop, where main parks per AUDIT-009) or another singleton-getter chain.
## Recommended next-session target
**AUDIT-017** should be a focused probe on:
1. **Dispatcher caller**: probe `0x822f1be8`, `0x822f1c04`, `0x822F1AA8` (main's frame-poll loop entry per AUDIT-009) + the entry of `sub_821752C0` (which jumps to `sub_82173DC8` per static xref). These reveal what main passes as listener struct + notification ID + r5 value to the dispatcher.
2. **State-advance writers**: byte-scan for the BE-u32 write of `0x40ba9a80+4` ANYWHERE — find every PC that does `addi r3, ?, 4; stw r?, 0(r3)` against this address. Add those PCs to the probe set.
3. **0x82181C28's deeper logic**: probe inside `sub_82181D48` (case 0xB's secondary predicate). Per disasm: it reads `[r3+0]+60` bit 30 (`rlwinm r11, r11, 0, 30, 30`) — find what writes that bit. If we make it return 1, case 0xB succeeds → `bctrl` fires → renderer cascade.
4. **Probe-machinery anomaly**: `sub_82174040` entry never fires despite mid-body PC 0x821741F0 clearly executed (lr=0x821741f4 of `sub_821737F0` fire). Cross-check whether `--branch-probe` skips the very first instruction of a function (mflr r12) or has another gap. **Verify before next session by adding 0x82174040, 0x82174044, 0x82174048 to a tiny probe and tracing.**
**Sharp 4-dim cascade prediction**: insufficient to make. AUDIT-017 needs to find what writes bit 14 / bit 15 of `[0x40ba9a80+4]` OR what writes the `[r3+0]+60` bit-30 field that gates `sub_82181D48`. If either is identifiable as a bl from a probed PC, the cascade is named.
## Discipline gate
| # | Condition | Pass? |
|---|---|---|
| 1 | Phase 1 named single failing kernel/xam import (α) or narrow internal-sub bug | **NO** — γ-class, no kernel boundary; gate is structural |
| 2 | Canary impl small | N/A |
| 3 | Sharp 4-dim cascade prediction | **NO** — needs further state-write triage |
| 4 | No new ABI plumbing | N/A |
| 5 | Fix doesn't touch renderer subsystem | N/A |
Boxes 1 + 3 fail. **STOP. Hand back per stop condition 1.** No fix attempted, no commit.
## Cascade snapshot (unchanged from AUDIT-015 / IO-004)
- swaps=2, draws=0
- 20 worker threads
- VdSwap=2, instructions=500M completed
- Canary-only exports unchanged: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`
- Stuck handles unchanged: 0x1004, 0x100c, 0x1020, 0x15e4, 0x1308 (Semaphore, 2 waiters tids 14+15), 0x160C, 0x42450b5c
## Trace artifacts (re-runnable)
- `audit-runs/audit-016-submitter-callers/probe.log` (run #1: 30 PCs, 11 fires, 9 KB)
- `audit-runs/audit-016-submitter-callers/probe.err` (run #1: 187 KB structured events)
- `audit-runs/audit-016-submitter-callers/probe2.log` (run #2: 18 PCs, 10 fires, 12 KB; +4 dump-addrs)
- `audit-runs/audit-016-submitter-callers/probe2.err` (run #2: 187 KB)
Re-run command (run #1):
```
PROBE="0x822AE1F0,0x822F55F0,0x822C8B50,0x822C6808,0x822B16E0,0x822F5728,\
0x822ADD70,0x821A9920,0x822ACAB8,0x821A8578,0x822AE12C,0x822ACB54,0x822ACB88,\
0x821A98FC,0x821AB1C0,0x82299250,0x82299724,0x822A4460,0x822A49B8,0x821A82A0,\
0x821A8464,0x82174040,0x82174018,0x82174030,0x82173EF8,0x82173EC4,0x82173EBC,\
0x82173DC8,0x82173ED8,0x82175338"
./target/release/xenia-rs exec sylpheed.iso --halt-on-deadlock \
--branch-probe="$PROBE" --dump-addr=0x40ba9a80 -n 500000000 \
> audit-runs/audit-016-submitter-callers/probe.log \
2> audit-runs/audit-016-submitter-callers/probe.err
```
## Constraints honored
- Stop condition 1: no narrow fix in scope. Hand back.
- Discipline gate failed boxes 1 + 3 ⇒ no fix.
- No code modifications — `--branch-probe` + `--dump-addr` from prior infra were sufficient.
- No git commit (no source changes; memory file + audit-findings.md update is documentation only).
- C++ runtime audit backlog (CPPBUG-AUDIT-001) not visited.
- No new ABI plumbing.
- No git push.
- Probe-machinery extension `git stash@{0}` (audit-012 dump-on-probe) NOT applied — fell back to multiple smaller runs per stop condition.

101
migration/claude-memory/project_xenia_rs_audit_017_state_bits_writer_2026_05_06.md Normal file
View File

@@ -0,0 +1,101 @@
---
name: KRNBUG-AUDIT-017 — bit-14/15 writer triage; gate is β-class with α tail (`[0x828F4070+64]==-1` early-exits sub_821737F0; `XamUserGetSigninState=stub_return_zero` would gate downstream branches even if β cleared)
description: 2026-05-06. Static + runtime probe of the listener-state writers. **5 oris-bit-14/15 + stw-+4 candidates** identified statically; **2 fire at runtime** (case-0xA at 0x82173e04 sets bit-15 once; sub_821737F0 work-path at 0x82173950 NEVER fires bit-14 because of upstream gate). **Decisive runtime evidence** — case-0xA SETS bit-15 at cycle 9183060, sub_821737F0 work-path enters at 9183561, but at 0x821738D8 reads `[r30+64]==-1` (where `r30=[0x828F48B0+0]=0x828F4070`), short-circuits to 0x82173938 → `r11=0` → no bit-14 set. The follow-up case-9 dispatch already cleared bit-15. After 4 startup notifications, no further dispatcher fires happen on `0x40ba9a80`, leaving `[+4]=0` permanently. **`[0x828F4070+64]` is initialized to -1 by `sub_821701c8` (Meyers ctor); the only non-(-1) writer is `sub_82184318` whose call chain bottoms in audit-009 renderer cluster (`sub_82187dd0 ← sub_82183ca8 ← sub_822919c8`)** — same γ-cluster blocked at audit-009. Bug class **β (guest-state read upstream)** with α tail. Master HEAD `d736a1d` unchanged.
type: project
originSessionId: audit-017-2026-05-06
---
## Hand-off summary
**Goal**: identify what should write bits 14/15 of `[0x40ba9a80+4]` (the listener dispatch-state-bits) so dispatcher case-9 stops early-exiting.
**Static writer scan** (5 candidates flagged: oris-with-0x1/0x2 followed by stw to +4 within 8 instructions):
| PC | Function | Sets bit | Target |
|---|---|---|---|
| 0x82173950 | sub_821737F0 | 14 | `[r28+4]` (= listener +4) — predicate work-path |
| 0x82173e04 | sub_82173DC8 | 15 | `[r31+4]` (= listener +4) — dispatcher case-0xA |
| 0x824d3ce8 | sub_824d3c78 | 15 | `[r8+4]` (struct stride 96, child via `[parent+184]`) |
| 0x824d3f24 | sub_824d3dc0 | 14 | `[r9+4]` (same pattern) |
| 0x82769b84 | sub_82766db0 | 15 | `[r3+4]` (struct stride 8 — false positive) |
**Runtime evidence** (`audit-runs/audit-017-state-bits-writer/probe{1,3,4,5}.log`, -n 500M):
- **Case-0xA fires once** at cycle 9183060 (PC 0x82173dfc, r3=0x40ba9a80) — sets bit-15 of `[0x40ba9a80+4]`. Confirmed by EOR dump: `[+0x0C]=0x000003E8` (= 1000, set by `subfic r11, r11, 1000` at 0x82173e30 in same arm).
- **sub_821737F0 work-path entered** at cycle 9183561 (lr=0x821737f8 from 0x82173874 `bl 0x821707C0`). Bit-15 cleared at 0x82173884 (`rlwinm r11, r11, 0, 16, 14` clears bit 15).
- **Bit-14 setter at 0x82173950 NEVER FIRES**. Why: at 0x821738E0, `cmpwi r3, -1; beq → 0x82173938` short-circuits because `r3=[r30+64]=0xFFFFFFFF`. r30 = `[0x828F48B0+0]` = `0x828F4070`. EOR dump confirms `[0x828F4070+64]=0xFFFFFFFF`.
- **Probe trace** at 0x82173938 fires with `r3=0xffffffff` (cycle 9188933) — direct confirmation of the early-exit.
- **bit-28 of `[0x828F4070+60]` IS set** at cycle 9224352 by `sub_821c4988:0x821c5450` (`ori r10, r10, 0x8; stw r10, 60(r11)`) — but 35,000 cycles AFTER the case-9 dispatcher fired, AFTER the dispatcher already early-exited. Even if it were earlier, sub_821737F0's bit-28 check at 0x821738F0 (`bne cr6, 0x82173938`) BRANCHES TO no-bit-14 IF bit-28 IS set — bit-28 is a NEGATIVE gate, not a positive one.
- **The actual positive gate is `[0x828F4070+64] != -1`**. `[0x828F4070+64]` is initialized to -1 at startup by `sub_821701c8` at 0x82170234 (`li r11, -1; stw r11, 64(r30)`).
**The specific code path that should set bits 14/15 of `[0x40ba9a80+4]`**:
1. `sub_82184318` (ctor) at 0x82184370 calls `bl 0x82456B58` (kernel handle creator), stores result via `stw r3, 64(r30)` at 0x82184374. This is the only writer of a non-(-1) value to offset 64 of the renderer-config sub-object.
2. Caller chain: `sub_82184318 ← sub_82187768:0x821877bc ← sub_82187dd0:0x82187e78 ← sub_82183ca8:0x82183cd8 ← {sub_822919c8, sub_82186760, sub_821c88d0}`. **`sub_822919c8` is one of the audit-009 renderer-cluster L1 entry points that has zero non-call xrefs** — registry-dispatched, never populated.
**Two orthogonal stubs uncovered (α tail)**:
- `XamUserGetSigninState` (xam.rs:48) is `stub_return_zero`. Even if β is fixed, sub_821737F0's bit-14 deep-eval at 0x82173904-0x82173938 tests the return; with 0, takes the no-bit-14 path in 2/3 sub-branches. Also `sub_822C2A80` at 0x822c2ab0 loops `XamUserGetSigninState(0..3)` searching for any signed-in user — also broken. Canary `xam_user.cc:90-101` returns `SignedInLocally=1` for the default profile.
**Bug class**: **β-dominant + α-tail.** Primary β is structural (renderer cluster unreachable, identical to audit-016's γ finding for the workitem-submitter chain — same bottom-out at sub_822919c8). Secondary α is `XamUserGetSigninState=stub_return_zero` which would gate downstream paths.
## Recommended next-session target
The β gate is the **same renderer cluster that audit-009 falsified an entry hypothesis for**. AUDIT-017 has now identified a SECOND productive path through that cluster (sub_82184318 ctor) but it's blocked at the same level (sub_822919c8 / sub_82187dd0 / sub_82186760 / sub_821c88d0 all xref-internal-only or top-out in cluster).
**This is structurally identical to audit-016**. Recommended pivot:
**Option A (continue probe layers)**: AUDIT-018 should probe `sub_82184318` entry, `sub_82187768` entry, `sub_82187dd0` entry directly to verify they are NOT entered at runtime, and walk one level deeper via xrefs to confirm. Probe set: `0x82184318, 0x82187768, 0x82187dd0, 0x82183ca8, 0x82186760, 0x821c88d0, 0x822919c8` + `0x82456B58` (the kernel allocator the ctor would call). If ALL 8 fail to fire at -n 500M, this confirms the same γ-class structural blocker as audit-009/-016.
**Option B (canary log diff for missing kernel calls)**: re-run `lutris lutris:rungameid/4` and capture canary's `xenia.log` with `kernel_state.log_kernel_calls=true` enabled, diff against ours during the boot window 9.0M-9.3M cycles. Specifically watch for any kernel call that would write a real handle into `0x828F4070+64` — likely a notification-listener or window-dispatch creator we're not implementing.
**Option C (α fix as cheap test)**: implement `XamUserGetSigninState` properly (return 1 for user_index 0; canary impl is 5 LOC). Predicted cascade: orthogonal — it would unblock sub_822C2A80's user-search loop and sub_8216F798's deep-eval, but would NOT unblock the listener dispatcher because β (`[+64]==-1`) is the dominant gate. Worth doing as it's α-class with cheap implementation, but **will not fire the cascade alone** unless β is also resolved.
**Sharp 4-dim cascade prediction**: NEEDS FURTHER TRIAGE. The β-gate is at the same level audit-016 stopped at. AUDIT-017 cannot break the loop; it can only refine the diagnosis: audit-016's "γ cluster never reached" finding is now reaffirmed via a completely different path (workitem-submitter → renderer; ctor-handle-allocator → renderer — both bottom out in `sub_822919c8` etc.).
## Discipline gate
| # | Condition | Pass? |
|---|---|---|
| 1 | Phase 1 named single failing kernel/xam import (α) or narrow internal-sub bug | **PARTIAL** — α component identified (XamUserGetSigninState) but it's not the dominant gate |
| 2 | Canary impl small | **YES** for α (5 LOC at xam_user.cc:90-101) |
| 3 | Sharp 4-dim cascade prediction | **NO** — β dominant, structural |
| 4 | No new ABI plumbing | N/A (no fix this session) |
| 5 | Fix doesn't touch renderer subsystem | N/A |
Boxes 1+3 fail. **STOP per stop condition 1.** No fix. No commit.
## Key file paths and PCs (for next session)
- `crates/xenia-kernel/src/xam.rs:48` — `XamUserGetSigninState` registered as `stub_return_zero`
- `xenia-canary/src/xenia/kernel/xam/xam_user.cc:90-104` — canary's signin_state impl
- `xenia-canary/src/xenia/kernel/xam/user_profile.h:101-103` — `signin_state()` returns `SignedInLocally=1`
- `xenia-canary/src/xenia/kernel/xam/xam_state.cc:48-51` — `IsUserSignedIn(0)` returns `profile != nullptr` (default profile loaded)
Static writers (sylpheed.db):
- 0x82173950 (sub_821737F0:bit-14 setter, gated by `[r30+64]!=-1` AND XamUserGetSigninState ret check)
- 0x82173e04 (sub_82173DC8 case-0xA:bit-15 setter — fires correctly)
- 0x82184374 (sub_82184318 ctor:writes [r30+64]=kernel-handle from sub_82456B58 — UNREACHED, in renderer cluster)
Probe artifacts:
- `audit-runs/audit-017-state-bits-writer/probe.log` (run #1: 23 PCs, 13 fires, 1.2KB)
- `audit-runs/audit-017-state-bits-writer/probe2.log` (refined 9 PCs, --quiet)
- `audit-runs/audit-017-state-bits-writer/probe3.log` (8 PCs + dump-addr 0x40ba9a80 + 0x828F48B0)
- `audit-runs/audit-017-state-bits-writer/probe4.log` (18 PCs covering all bit-28 setters + sub_821737F0 paths — found sub_821c4988 fires at cycle 9224352)
- `audit-runs/audit-017-state-bits-writer/probe5.log` (4 PCs to capture sub_821c4988 entry lr — confirmed self-recursive entry)
## Constraints honored
- Stop condition 1: no narrow fix in scope. Hand back.
- Discipline gate failed boxes 1+3 ⇒ no fix.
- No probe-machinery extension (used existing --branch-probe + --dump-addr).
- No git commit (read-only audit).
- No git push.
- C++ runtime audit backlog (CPPBUG-AUDIT-001) not visited.
## Cascade snapshot (unchanged from audit-016)
- swaps=2, draws=0
- 20 worker threads
- VdSwap=2, instructions=500M completed
- Canary-only exports unchanged: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`
- Stuck handles unchanged (incl. 0x1004, 0x100c, 0x1020, 0x15e4, 0x1308, 0x160C, 0x42450b5c).

107
migration/claude-memory/project_xenia_rs_audit_018_canary_diff_2026_05_06.md Normal file
View File

@@ -0,0 +1,107 @@
# KRNBUG-AUDIT-018 — canary-log diff identifies α-class stub `KeResumeThread` (DIAGNOSTIC 2026-05-06, READ-ONLY)
**Status**: read-only diagnostic. No fix landed. Master HEAD `7ed6192` unchanged. Tests 600. Lockstep `instructions=100000006`.
## Context
Three prior sessions (audit-009 / audit-016 / audit-017) identified a γ-cluster structural blocker reaching `sub_82184318:0x82184374` (the only static writer of `[0x828F4070+64]`). The audit-018 prompt directed: stop probing the same cluster; instead, diff our kernel-call sequence vs canary's `xenia.log` for any kernel/xam call canary makes that we don't, with side-effects upstream of `sub_82184318` or on `[0x828F4070+64]`.
## Method
1. Captured `audit-runs/audit-018-canary-diff/ours.log` at -n 500M with full default tracing (no probe extension).
2. Inspected `/home/fabi/xenia_canary_windows/xenia.log` (May 4, 348 KB, full Sylpheed boot reaching active rendering with `XamInputGetCapabilities` polling and `VdGetSystemCommandBuffer/VdRetrainEDRAM` on a `KeReleaseSemaphore(828A3230)` ticker).
3. Set-diffed kernel-call function names (regex-filtered to discard hex-address tokens).
## Decisive findings
1. **Function-name set diff**: only 2 kernel calls appear in canary that don't appear in our log: `ExTerminateThread`, `KeReleaseSemaphore` — both already on the audit-006 canary-only export queue. Everything else canary calls, we also call.
2. **`KeReleaseSemaphore(828A3230, 1, 1, 0)` is hammered by canary tid `F800006C`** repeatedly (the audio render-frame ticker). This thread is created by `ExCreateThread(701CF294(00000000), 00000000, 00000000, 00000000, 824D2878, 00000000, 10000001)` — entry `0x824D2878`, ctx=0, flags=0x10000001 (suspend bit set). Canary then immediately does `ObReferenceObjectByHandle(F800006C, ...) → 3005B018`, `KeSetBasePriorityThread(3005B018, 0xF)`, **`KeResumeThread(3005B018)`**, `ObDereferenceObject`. Same pattern for second worker entry `0x824D2940` (ctx=0, flags=0x20000001).
3. **In our run, both these threads are `Blocked(Suspended)` at end-of-run (-n 500M)**. Final-state diagnostic excerpt:
- `hw=4 idx=0 tid=9 state=Blocked(Suspended) pc=0x824d2878 lr=0xbcbcbcbc`
- `hw=5 idx=2 tid=10 state=Blocked(Suspended) pc=0x824d2940 lr=0xbcbcbcbc`
Counter `KeResumeThread = 2` and `NtResumeThread = 6` — exactly matching canary's call pattern.
4. **Root cause**: `crates/xenia-kernel/src/exports.rs:3658-3664`
```rust
fn ke_resume_thread(ctx: &mut PpcContext, _mem: &GuestMemory, state: &mut KernelState) {
// r3 = thread_ptr (KTHREAD). We don't track KTHREAD ↔ HW mapping through
// guest memory addresses, so accept and succeed. Real NtResumeThread
// below handles the handle-based path properly.
ctx.gpr[3] = 0;
let _ = state;
}
```
This is a **stub_success no-op**. It does not actually resume the thread. The guest's `ObReferenceObjectByHandle` cookie returns the handle (per `exports.rs:3787-3807` — `out_ptr` receives the handle as a stable cookie), so the `thread_ptr` argument to `KeResumeThread` IS just the handle. Our `find_by_handle(handle).map(|r| state.scheduler.resume_ref(r))` would work — but `ke_resume_thread` doesn't even attempt the lookup.
Canary `xboxkrnl_threading.cc:216-227`:
```cpp
dword_result_t KeResumeThread_entry(pointer_t<X_KTHREAD> thread_ptr) {
X_STATUS result = X_STATUS_SUCCESS;
auto thread = XObject::GetNativeObject<XThread>(kernel_state(), thread_ptr);
if (thread) {
result = thread->Resume();
} else {
result = X_STATUS_INVALID_HANDLE;
}
return result;
}
```
5. **Cross-cluster confirmation**: tid=17 (entry=0x82170430, ctx=0x828F4070) IS spawned and parks at `Blocked(WaitAny { handles: [5604] })` (handle 0x15E4) — exactly the audit-014 / audit-017 listener-dispatch event. Worker body at `0x82170430-0x82170554` reads `[r29+56] (=[0x828F40A8])` as its loop predicate (NOT `+64` as audit-017 stated; +64 may still be the dispatch-state-bits but +56 is the immediate worker gate). Until tids 9/10 actually run their bodies, the audio-driven side of the cascade never starts and the listener-dispatch-state-bits chain stays gated on -1.
## Bug class
**α (named import stub_success on a load-bearing export)**. Specifically: `KeResumeThread` is registered (xenia-canary `kImplemented`) but our impl is a no-op cookie-returner. The 2 known canary-only exports (`KeResumeThread`'s **call chain** completes — we mark it called but the work isn't done; `ExTerminateThread` is genuinely unhit because the audio workers never reach their exit path because they never start).
Fixing `KeResumeThread` is exactly the kind of small, narrow, ABI-correctness change the discipline gates were waiting for.
## Discipline gate
- Box 1 (named bug class with concrete evidence): **YES** — α-class, name+location identified at `exports.rs:3658-3664`.
- Box 2 (narrow fix ~30-80 LOC): **YES** — ~5 LOC, mirror `nt_resume_thread` pattern (lines 3666-3679) using `find_by_handle(handle).resume_ref(r)`.
- Box 3 (sharp 4-dim cascade prediction): see below.
- Box 4 (no renderer/GPU changes): YES.
- Box 5 (lockstep determinism preserved): preserved by 2 prior parallel landings (XamUserGetSigninState, IO-004); same pattern.
All 5 boxes pass — first time since audit-013/IO-004.
## Sharp 4-dim cascade prediction (KRNBUG-IO-005 / KRNBUG-α-005, next session)
**Fix**: replace `ke_resume_thread` body to mirror `nt_resume_thread`:
```rust
fn ke_resume_thread(ctx: &mut PpcContext, _mem: &GuestMemory, state: &mut KernelState) {
let handle = resolve_pseudo_handle(state, ctx.gpr[3] as u32);
let prev = state.scheduler.find_by_handle(handle).map(|r| state.scheduler.resume_ref(r)).unwrap_or(0);
ctx.gpr[3] = prev;
}
```
**Predicted cascade**:
1. **Dimension A — thread liveness**: tids 9 and 10 leave Suspended state, run bodies of `0x824D2878 / 0x824D2940`. Both are XAudio voice-render workers (call `KeReleaseSemaphore(828A3230)` repeatedly per canary). Final-state thread count moves from "2 Blocked(Suspended)" to "2 Blocked(WaitAny ...)" or "2 Ready" depending on instruction budget.
2. **Dimension B — kernel call counters**: `KeReleaseSemaphore` appears with non-zero count for the first time. Audio system advances; `XAudioSubmitRenderDriverFrame` likely fires (currently 0 calls). `NtSetEvent` count rises substantially (audio frame-complete signaling).
3. **Dimension C — canary-only exports**: 2→1 (`KeReleaseSemaphore` no longer canary-only). `ExTerminateThread` likely still missing (workers exit only on shutdown). Possibly some new exports surface that the audio path needs.
4. **Dimension D — listener / dispatch-state-bits**: NOT cleanly predictable. Strongest hypothesis: with audio workers running, the audio-side callback path advances enough state to let `sub_82184318` chain enter (via the audio-init → kernel-handle-create flow). If it doesn't, the cascade stops at A+B+C and the γ-cluster is genuinely independent. **Either outcome is decisive new information**.
**Lockstep risk**: low — `nt_resume_thread` pattern is already proven non-flaky. Tests 600→601 expected (one new test for `ke_resume_thread` actually resuming).
## Recommended next session
Implement the 5-LOC fix above in a separate `ke-resume-thread/p0-canary-mirror` branch, run lockstep ×2, capture full diagnostic, evaluate cascade prediction.
If Dimension D fires (listener `[+64]` becomes non-(-1)): the γ-cluster blocker collapses; renderer cascade unblocks; AUDIT-009-018 line of investigation closes.
If Dimension D does NOT fire: the bug-list narrows to `ExTerminateThread` + 1-3 new exports surfaced by the audio path, AND the γ-cluster is genuinely independent — pivot per audit-017 Option B (memory-watch instrumentation on `0x828F4070+64`).
## Trace artifacts
- `audit-runs/audit-018-canary-diff/ours.log` (~700 lines, kernel-call traces + final-state thread diagnostics)
- `audit-runs/audit-018-canary-diff/ours.stdout.log` (counters + thread states)
- Canary log untouched: `/home/fabi/xenia_canary_windows/xenia.log` (May 4, 5260 lines, full boot)
- Diff scripts inline in this file (set-diff via `comm -23`/`comm -13` on filtered function names)
## Methodology note
The "ours-only" set in the diff (NtReadFile, NtWaitForSingleObjectEx, NtSetEvent, RtlEnterCriticalSection, etc.) is a **logging-level artifact**, not a real divergence: canary's `xenia.log` is debug-level (`d>`) per-call but suppresses many high-frequency calls that we count via metrics. The "canary-only" set is the actionable signal because it shows what a working boot needs that we don't provide. Two entries, one of which is a bug-of-omission (KeResumeThread no-op stub) AND blocks 2 worker threads — a rare clean kernel-boundary cause.

133
migration/claude-memory/project_xenia_rs_audit_023_canary_diff_2026_05_06.md Normal file
View File

@@ -0,0 +1,133 @@
# KRNBUG-AUDIT-023 (2026-05-06, READ-ONLY w.r.t. xenia-rs; Path B canary patch+rebuild+diff)
## Goal
Capture canary's runtime guest memory at first XamNotifyCreateListener call (mask=0x2F),
diff against ours at the same target addresses (especially the audit-017 0x828F4070+64
hypothesis), and identify what populator's *effect* (data) canary has that ours lacks.
## Canary patch landed (then reverted)
`xenia-canary/src/xenia/cpu/cpu_flags.{h,cc}`: declare/define `DEFINE_string(memory_dump_path,...)`.
`xenia-canary/src/xenia/kernel/xam/xam_notify.cc::XamNotifyCreateListener_entry`: on first
call (atomic-bool gated), `std::filesystem::resize_file(path, 2_GiB)` + `MappedMemory::Open`
+ `Memory::Save(&stream)`. 44 LOC total (≤50 budget). Trace at
`xenia-rs/audit-runs/audit-023-canary-diff/canary-patch.diff`.
**Critical fix**: `PosixMappedMemory::WrapFileDescriptor` mmaps the file at its current size
without extending it; v1 patch (no `resize_file`) SIGBUS'd in `__memcpy_avx_unaligned_erms`
during `BaseHeap::Save` first 8-byte qword write. Pre-sizing to 2 GiB fixes it.
## Build outcome
SUCCESS (Linux Debug, clang++14, ~6 minutes incremental from a CMake-regenerate-forced
full rebuild). Binary: 247065320 bytes. `strings | grep memory_dump_path` confirms flag
embedded. Symlink `/home/fabi/xenia-canary -> RE Project Sylpheed/xenia-canary` was
required because the build dir was originally CMake-configured at the no-spaces path.
## Pre-existing canary blocker
`XexInfoCache::Init` SIGBUS at line 1406 (reading `GetHeader()->version` from mmap'd
infocache file). Worked around with `--disable_instruction_infocache=true`.
## Memory dump captured
Path: `/tmp/audit-023-canary-memory.dump` (also copied to `xenia-rs/audit-runs/audit-023-canary-diff/canary-memory.dump`)
Size: 216,004,608 bytes (logged by AUDIT-023 message in canary stdout).
Heap commit profile (parsed):
- v00000000 (4K page): 447 committed
- v40000000 (64K): 57
- **v80000000 (64K, XEX): 146**
- v90000000 (4K): 0
- physical (4K): 48105
## Parser bit-layout discovery
`PageEntry` bitfields in canary's compiled binary place `state` at qword bits 60-61, NOT
at the declaration-order position 48-49. Likely because clang's bitfield allocator splits
across uint32_t storage units. Empirically verified: with state at bit 60, parser cursor
lands EXACTLY at file size 0xCDFF800 (= 216,004,608); with state at bit 48 it lands at
0x3EE800 (~4 MiB, header-only, missing all payload).
## Diff results — canary-vs-ours at target addresses
### Listener struct family 0x828F4070 (audit-017's hypothesized populator target)
**Canary at first-listener time: ALL ZEROS.**
**Ours at -n 50M: highly populated** (vtable/object data, event handles 0x15ec/0x15e4,
floats 0.6f, etc.).
This is the OPPOSITE of audit-017's expectation. Our impl populates 0x828F4070 family
EARLIER than canary does at the first-listener moment. **Doesn't refute audit-017** —
canary's dump fired BEFORE the populator runs (kernel-init phase, not late-game phase).
### 0x828E1F08 (the dispatcher-pointer slot)
- canary: `00 00 00 00`
- ours: `40 11 18 90` (heap pointer to our XNotifyListener struct)
**Different mechanism.** Ours stores the listener pointer at this fixed slot; canary
doesn't (canary uses a separate `KernelState::notify_listeners_` vector and never
writes to guest memory at 0x828E1F08).
### 0x828F3D08 (audit-003 dispatcher for handle 0x100c)
Identical except handle namespaces:
- canary: `f8000024 f8000020` at +0x40 (canary uses 0xF8xxxxxx kernel-handle range)
- ours: `00001024 00001020` at +0x40 (ours uses 0x1xxx range)
This is a CONVENTION difference — handles work, just numbered differently. NOT a bug.
### 0x828F3D80, 0x828F3F00 (worker dispatchers)
- canary uses `0xBC...` host-physical aliases (vC0000000+) for some pointers.
- ours uses `0x40...` virtual heap pointers (v40000000+).
Both are valid heap addresses, different aliasing convention. Need careful interpretation.
### 0x828F4838 (audit-017 area near 0x828F48B0 cluster)
**Notable ASCII string divergence:**
- canary +0x08: `58 45 4E 00` = ASCII `"XEN\0"` (likely set by xboxkrnl as a struct magic)
- canary +0x0C: `f8000034` (canary handle)
- ours +0x08: `00 00 00 00 00 00 00 00` (zero — magic + handle MISSING)
Also +0x60: canary has `f800002c f8000028` (handles); ours `00001030 00001028` (handles).
### audit-009 cluster L1 PCs visible in canary's dump
ALL 6 cluster L1 PCs (0x822919C8, 0x82293448, 0x82288028, 0x82292d80, 0x822851e0,
0x82286bc8) appear at addresses 0x82124xxx. INVESTIGATED — this is the static `.pdata`
exception-handler table loaded from the XEX image; OUR impl has identical bytes there
(verified `cargo run --dump-addr=0x82124800,0x82124900` matches canary byte-for-byte).
This is NOT a populator target; it's static rdata.
## Bug-class classification
**The audit-017 hypothesis (β-class blocker `[0x828F4070+64]==-1`) cannot be confirmed
or refuted from this dump because canary's dump fired too early.** At first-listener,
neither side has populated 0x828F4070; both are zero in canary, populated in ours
(since ours runs to -n 50M).
The MORE INTERESTING new finding: **canary stores ASCII "XEN" at 0x828F4840 + a handle
at 0x828F4844**, ours doesn't. This is a populator effect for a struct that may or may
not be on the deadlock-causal path. Address 0x828F4838 is inside the audit-016/017
cluster (`[0x828F48B0+0]=0x828F4070` chain).
Discipline gate: 1+3 fail (no probe runtime confirmation; populator unknown).
## Sharp next-session prediction OR strategic pivot
**RECOMMENDED NEXT (AUDIT-024)**: refine the canary dump trigger to fire MUCH LATER —
e.g., at first NtSetEvent after some N seconds, or at the moment the renderer has done
its first XAudioSubmitRenderDriverFrame. That gives a fair like-for-like at a deeper
runtime point.
Concrete approach: re-apply canary patch but trigger on Nth XamNotifyCreateListener call
(say 5+) OR on a specific notification ID matching mask 0x2F's audio events
(e.g., 0x000A0000 audio-init complete). This will give us canary's view of 0x828F4070
WHEN populated — answering audit-017 directly.
**Alternative low-effort pivot**: investigate the "XEN\0" string at canary's 0x828F4840.
Static-search canary's xboxkrnl source for `"XEN"` write to a guest struct field. If
found, that's exactly the missing populator.
## Milestone status
HEAD: master `d9e40d3` unchanged. Tests 604, lockstep `instructions=100000003` preserved.
Canary patch reverted (working tree clean). Symlink `/home/fabi/xenia-canary` removed.
Core dumps from failed canary launches retained in `/var/lib/systemd/coredump/`.
Trace artifacts (retained):
- `xenia-rs/audit-runs/audit-023-canary-diff/canary-memory.dump` (216 MB)
- `xenia-rs/audit-runs/audit-023-canary-diff/canary.log`
- `xenia-rs/audit-runs/audit-023-canary-diff/canary-patch.diff` (re-applyable)
- `xenia-rs/audit-runs/audit-023-canary-diff/parse_dump.py`
- `xenia-rs/audit-runs/audit-023-canary-diff/diff_canary_ours.py`
- `xenia-rs/audit-runs/audit-023-canary-diff/diff.txt`
- `xenia-rs/audit-runs/audit-023-canary-diff/ours-{dump,extra,pdata}.{log,err}`

78
migration/claude-memory/project_xenia_rs_audit_024a_canary_delayed_trigger_2026_05_06.md Normal file
View File

@@ -0,0 +1,78 @@
# KRNBUG-AUDIT-024A — Canary memory-dump diff at delayed trigger (2026-05-07)
## Status
READ-ONLY. No xenia-rs source change. Canary patch applied + reverted; `git status` clean. Master HEAD `d9e40d3` unchanged. Tests 604, lockstep `instructions=100000003` preserved.
## Context
Sequel to AUDIT-023. AUDIT-023 captured canary memory at first `XamNotifyCreateListener` (very early). Result: `[0x828F4070+64]` was zero in canary at that moment, suggesting populator hadn't run yet. AUDIT-024A re-runs the experiment with a much later trigger to capture post-populator state.
## Patch summary
Diff against `xenia-canary canary_experimental` (HEAD upstream-5-behind):
- `src/xenia/cpu/cpu_flags.{h,cc}` (8 LOC): same `DEFINE_string(memory_dump_path, ...)` flag from audit-023.
- `src/xenia/kernel/xboxkrnl/xboxkrnl_audio.cc` (31 LOC): hook in `XAudioSubmitRenderDriverFrame_entry` — atomic-bool first-call gate, pre-size 2 GiB, mmap, `Memory::Save`, close.
- Total: **39 LOC** (target was ≤50).
Build: incremental `ninja -f build-Debug.ninja xenia_canary` after creating symlink `/home/fabi/xenia-canary -> /home/fabi/RE Project Sylpheed/xenia-canary` (CMake cache references the bare path). 16 ninja targets, ~10 s relink. Required `--disable_instruction_infocache=true` runtime workaround (preexisting canary bug).
## Capture
Run: `xenia_canary sylpheed.iso --log_level=3 --disable_instruction_infocache=true --memory_dump_path=/tmp/audit-024a-canary-memory.dump`. Dump materialised at 260,659,200 bytes (~248.6 MiB). Larger than audit-023's 216 MB — consistent with deeper boot. Canary log line confirms: `AUDIT-024A: dumping guest memory ... (XAudioSubmitRenderDriverFrame)` then `wrote 260659200 bytes`.
Pre-dump telemetry confirms post-populator state: `KeReleaseSemaphore(0x828A3230, 1, 1, 0)` firing repeatedly (audio buffer-completion semaphore — audit-018 producer prediction validated), VdSwap, VdRetrainEDRAM, multiple texture loads, XamInputGetCapabilities all firing.
## Findings
### `[0x828F4070+64]` β-class hypothesis FALSIFIED
`[0x828F40B0]` (=0x828F4070+64) at first `XAudioSubmitRenderDriverFrame`:
- **CANARY**: all zeros for at least 0x40 bytes.
- **OURS @ -n 500M**: `ff ff ff ff 00 00 00 00 ...` (audit-017's `-1` sentinel from sub_821701c8).
AUDIT-017's hypothesis that `[0x828F4070+64]==-1` blocks the bit-14 setter at `0x82173950` is now **directly falsified**: canary, while running steady-state audio frame submission, has this slot at zero — never advanced past init. The bit-14 path's actual gate must admit `[+64]==0`, or canary takes a different control path entirely. Either way, the β-blocker thesis (a non-(-1) write to `[+64]` is a precondition for renderer progress) is wrong.
### `0x828F4838+0x08` `"XEN\0 + 0xF8000034"` divergence stable
Canary still has `"XEN\0"` magic + kernel handle `0xF8000034` at +0x08. Ours has zeros. **Confirmed stable across audit-023 (very early) and audit-024A (late) trigger points** — populator wrote this field during early init, before even the first `XamNotifyCreateListener`. Heap pointers + counts at `0x828F4838 +0x20..+0x60` populated in both (canary `0xBC36xxxx`, ours `0x4024xxxx`).
### `0x828A3230` audio semaphore (canary only)
Canary state at `0x828A3230`: state-quad `0x00000005`, `"XEN\0"` + handle `0xF8000070` at +0x08, release-count `01000000` at +0x14, chain at +0x18 / +0x28 with handles `0xF8000080` / `0xF800007C` and `0xBE628EDC1FCA7000` at +0x38. In ours: `KeReleaseSemaphore=0` (still canary-only); producer chain unreached at -n 500M.
### `0x828F48B0+0x24=0x828F3EC0`
Canary correctly stores the audit-003 dispatcher addr for handle 0x100c. Confirms singleton-pool layout, populated identically in both runtimes.
## Bug class
Drop β-class (`[+64]` poison) hypothesis. Reclassify as **γ-deep**: the gate between audit-013's IO-004 reach (sub_82173DC8 dispatching) and the audio producer chain firing is a multi-step renderer/audio init that fires `XAudioSubmitRenderDriverFrame` in canary but never in ours.
Counters in our run: `XAudioRegisterRenderDriverClient=1`, `KeInitializeSemaphore=1` — registration ran and the buffer-completion semaphore was allocated. But the audio thread that calls `XAudioSubmitRenderDriverFrame` never starts feeding frames.
## Next session — sharp prediction
Two parallel tracks:
(1) **AUDIT-024B (sister session)**: static-search canary source for the writer of `"XEN\0" + 0xF8000034` magic. The `"XEN" + handle` pattern is the canonical type-tag emitted by `kernel/util/object_table.cc` when a kernel object is committed to guest memory. If 024B names the writer, cross-reference with our canary-only export queue to identify the missing kernel call.
(2) **Audio-thread-start probe**: name the kernel call that starts the audio frame submission. `XAudioRegisterRenderDriverClient_entry` returns a `0x41550000 | index` driver handle in canary; the game then has to spawn a worker thread that feeds frames. If our impl returns a working handle but the game doesn't spawn, the gate is in pure-guest code (δ); if we don't return a handle, the gate is in our `XAudioRegisterRenderDriverClient` impl (α). Counter = 1 in both, so likely δ — but probe needed.
## Cascade prediction (4-dim) for next-session fix
If a future fix lands the audio-thread-start gate:
- **A**: `XAudioSubmitRenderDriverFrame` count > 0
- **B**: `KeReleaseSemaphore` count > 0 (exits canary-only export queue)
- **C**: `[0x828A3230+0x14]` becomes 1
- **D**: open — VdSwap may or may not be paced by audio.
## Trace artifacts
- `audit-runs/audit-024a-canary-diff/canary-memory.dump` (248.6 MiB)
- `audit-runs/audit-024a-canary-diff/canary.log`
- `audit-runs/audit-024a-canary-diff/canary-patch.diff`
- `audit-runs/audit-024a-canary-diff/canary-state.txt`
- `audit-runs/audit-024a-canary-diff/canary-extra.txt`
- `audit-runs/audit-024a-canary-diff/ours-dump.{log,err}`
- `audit-runs/audit-024a-canary-diff/diff.txt`

195
migration/claude-memory/project_xenia_rs_audit_025_audio_thread_start_2026_05_06.md Normal file
View File

@@ -0,0 +1,195 @@
# KRNBUG-AUDIT-025 — Audio Thread-Start Gate (READ-ONLY, 2026-05-07)
Master HEAD at start: `d9e40d3`. **Path 2 sister session merged mid-session**;
HEAD at end: `de5a15e` (`xobj-stashhandle/p0-canary-mirror` — 7 LOC stamp of
`XEN\0` + handle in `ensure_dispatcher_object`, KRNBUG-α-006 LANDED).
## Executive summary
Goal: identify the gate between successful `XAudioRegisterRenderDriverClient`
(both runtimes call once with identical return `0x41550000`) and the audio
worker submitting frames (canary fires repeatedly, ours never).
**Outcome: γ-DEEP (vtable-driven indirection, no clean kernel-stub gap).**
The audio init runs to completion in our impl: heap object allocated,
DISPATCHER_HEADERs for `0x828A3230` (sem) / `0x828A3244` (event) / `0x828A3254`
(event) initialized, worker thread tid 9 (entry `0x824D2878`) spawned +
resumed, `ExRegisterTitleTerminateNotification(0x828A3210, 1)` registered.
Worker is correctly parked on `KeWaitForSingleObject(0x828A3254)` waiting for
a job-submit wake-up. **The wake-up function `sub_824D23B0` is invoked only
via the audio_system vtable (`[r31+0]=0x82006CF4`)** — there are zero static
direct-call xrefs to its body at `0x824D2BD8`. The vtable-method caller would
be a per-frame audio update from the renderer/scenegraph — i.e., the same
`0x82287000-0x82294000` cluster identified by AUDIT-009 as unreached.
**The audio gate IS the renderer gate.** No new bug class. The fix is the
same one that's been gating draws/swaps since AUDIT-009/016/017 — a deep
γ-class chicken-and-egg in the dispatch-vtable population.
## XAudioRegisterRenderDriverClient impl comparison
**Ours** `crates/xenia-kernel/src/exports.rs:2705-2745`:
- `r3 = callback_ptr` (guest pair: PC + arg)
- Reads `mem[callback_ptr] = callback_pc`, `mem[callback_ptr+4] = callback_arg`
- `state.heap_alloc(4) → wrapped`; `mem[wrapped] = callback_arg` (BE)
- `state.xaudio.register({pc, arg, wrapped}) → index`
- `mem[driver_ptr] = 0x41550000 | (index & 0xFFFF)`; returns `STATUS_SUCCESS`
- **No host audio worker thread.** A periodic ticker
(`xaudio_tick_instr`/`tick_wallclock`) is wired but default-OFF behind
`--xaudio-tick` because under it the registered callback enters infinite
KeWait and regresses swaps 2→1 (per KRNBUG-XAUDIO-PRODUCER-001).
**Canary** `xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_audio.cc:56-82`:
- Same arg parsing.
- Calls `audio_system->RegisterClient(callback, arg, &index)` —
`xenia/apu/audio_system.cc:202-237`. **`RegisterClient` does TWO important
things our impl skips**: (a) calls `client_semaphore->Release(queued_frames)`
on a HOST `xe::threading::Semaphore` (canary's host audio worker thread,
spawned at `AudioSystem::Setup`, sleeps on this); (b) creates a host-side
`AudioDriver` (XAudio2 / SDL backend) tied to the host semaphore.
- `mem[driver_ptr] = 0x41550000 | (index & 0xFFFF)`; returns success.
**Difference**: canary's host audio worker pumps the registered callback at
the audio frame rate. **In Sylpheed's case, the guest also has its OWN
audio worker (tid 14 = `F800006C`, entry `0x824D2878`) which loops Wait-on-
`0x828A3254` → Process → Release(`0x828A3230`) → SetEvent(`0x828A3244`).** The
guest worker is what canary's xenia.log shows hammering KeReleaseSemaphore
268+ times. So even without canary's host-worker callback firing, the guest
worker should run on its own — IF something signals `0x828A3254` repeatedly.
## Canary log audio init (xenia.log lines 1527-1606)
1. `MmAllocatePhysicalMemoryEx` — alloc audio heap.
2. **L1529** `KeInitializeSemaphore(0x828A3230, 0, 6)` — buffer-completion sem.
3. **L1531** `ExRegisterTitleTerminateNotification(0x828A3210, 1)`.
4. **L1532** `ExCreateThread(entry=0x824D2878, ctx=0, flags=0x10000001)` — audio worker.
5. **L1533** handle `F800006C` allocated.
6. **L1536-37** `KeSetBasePriorityThread(15)` + `KeResumeThread`.
7. **L1539** `ExCreateThread(entry=0x824D2940, ctx=0, flags=0x20000001)` — second audio thread.
8. **L1546** `K> F800006C XThread::Execute thid 14`.
9. **L1549** `XAudioRegisterRenderDriverClient(0x701CF210→0x824D6640, 0xBDFBA658)`.
10. **L1551** `client 0 registered successfully`.
11. **L1555-1606+** thread `F800006C` hammers `KeReleaseSemaphore(0x828A3230, 1, 1, 0)`.
In our run (`audit-runs/audit-024a-canary-diff/ours-dump.err`): tid 9 spawned
(entry `0x824d2878`), tid 10 spawned (entry `0x824d2940`), `KeInitializeSemaphore=1`,
`ExRegisterTitleTerminateNotification=3`, `XAudioRegisterRenderDriverClient=1`,
**`KeReleaseSemaphore=0`**, `KeSetEvent=1`, `KeWaitForSingleObject=5`,
`KeResumeThread=2`. Init reaches the same point but the worker never gets a
job-submit signal.
## Audio worker disasm (entry 0x824D2878)
```
LOOP_HEAD (0x824D28B8):
r3 = 0x828A3254 # auto-reset event
bl KeWaitForSingleObject(r3, reason=3, mode=1, alertable=0, NULL) # 0x824D28CC
r3 = mem[0x828A3264] # = audio_system_obj heap ptr
r11 = mem[r3+300] # audio_active flag
r31 = (r11 == 0) ? 1 : 0 # cntlzw + rlwinm
if r31 == 0 (audio_active != 0):
bl sub_824D2108 / sub_824D21F0 # process job
KeSetEvent(0x828A3244, 1, 0)
goto LOOP_HEAD
else (shutdown):
r5 = mem[r3+304] - 1
if r5 != 0: KeReleaseSemaphore(0x828A3230, r5, 1) # 0x824D2904
KeSetEvent(0x828A3244, 1, 0)
return # exit thread
```
Wake source for `0x828A3254`: only `sub_824D23B0` (KeSetEvent at `+0x54`,
`+0x4FC`, `+0x688`). `sub_824D23B0+0x678` writes `[r31+300] = current_thread`
(at `0x824D2A28`) so subsequent worker iterations take the active branch.
## Caller chain of sub_824D23B0
Static xrefs (DuckDB `xrefs` table):
- `sub_824D23B0` ← `sub_824D2B08+0xE4` (= `0x824D2BEC`) — ONE call.
- But `sub_824D2B08` returns at `0x824D2BD4` BEFORE `0x824D2BEC`. The body
containing the bl is `0x824D2BD8..0x824D2C04` — a separate inline function
the static analyzer didn't carve out as its own `functions` row.
- ZERO static call-xrefs to `0x824D2BD8`. **Vtable indirection.**
- `sub_824D2B08` (the constructor) sets `[r31+0] = 0x82006CF4` (vtable in
`.rdata`). The vtable's slot for the job-submit method points at
`0x824D2BD8`. Caller code does
`lwz r11, 0(r_audio_obj); lwz r11, OFF(r11); mtctr r11; bctrl`.
## Probe set fired (audit-runs/audit-025-audio-thread-start/probe.log)
`--pc-probe=0x824D23B0,0x824D2404,0x824D28CC,0x824D28D0,0x824D28E4,0x824D290C,0x824D291C,0x824D2928,0x824D2930,0x824D2DAC,0x824D2DF8,0x824D2DFC --dump-addr=0x828A3210,0x828A3230,0x828A3244,0x828A3254,0x828A3214 -n 500_000_000 --halt-on-deadlock`
Fired (1 of 12): `0x824D2DF8` tid=1 cycle=7,470,631 (the
ExRegisterTitleTerminate call inside `sub_824D2C08`). All audio-job-submit
PCs (`sub_824D23B0` + `0x824D2404` `KeSetEvent(0x828A3254)`) **never reached**.
Dispatcher dump confirms init success (and Path 2's StashHandle stamp):
- `0x828A3254` Event sync: type=0x01, sig=0, +0x08="XEN\0", +0x0C=0x828A3254
- `0x828A3230` Semaphore: type=0x05, count=0, limit=6, +0x08="XEN\0"
- `0x828A3244` Event sync: type=0x01, sig=0
- `mem[0x828A3264]=0x4250DEDC` (audio_system heap object pointer set)
Thread state: tid 9 `Blocked(WaitAny [0x828A3254])` at pc=0x824D28D0,
waiters=[9], signal_attempts=0 — the wait was queued and nothing has signaled
since.
## Bug class classification: γ-DEEP (vtable-driven)
- α (load-bearing stub): NO. `XAudioRegisterRenderDriverClient` /
`KeInitializeSemaphore` / `KeWaitForSingleObject` / `KeSetEvent` /
`ExCreateThread` / `KeResumeThread` all match canary semantically.
- β (memory predicate): NO. `[r3+300]` is at heap offset on the `0x4250DEDC`
object; the worker correctly reads zero (audio_active not yet set) — but
this isn't the *blocker*; the worker would loop normally if KeSetEvent
fired periodically because each wake attempts the read again.
- γ-deep (multi-step indirection): YES. The audio job-submit is a vtable
method on the audio_system object. Caller is a periodic frame-loop in
the renderer/scenegraph (audit-009 unreached cluster).
This is a confirmation of audit-009/016/017's γ-class hypothesis from a new
angle. Path 2's StashHandle fix (KRNBUG-α-006) does not unblock it because
the missing piece is not "what kernel call writes XEN\0" — it is "what
populates the listener-dispatch vtable so the renderer can route per-frame
audio updates to `sub_824D23B0`".
## Discipline gate
- Box 1 (canary citation): PASS — `xenia/apu/audio_system.cc:202-237`,
`xboxkrnl_audio.cc:56-82`.
- Box 2 (LOC ≤ 30): N/A.
- Box 3 (runtime probe shows reach): **FAIL** — `sub_824D23B0` never reached.
- Box 4 (sharp 4-dim cascade): N/A (no fix this session).
- Box 5 (lockstep deterministic): N/A (no source modified).
## Sharp next-session direction
(A) **Strategic pivot (recommended)**: stop chasing audio. The audio gate IS
the renderer gate. Concentrate on AUDIT-009's `0x82287000-0x82294000`
cluster's L1 callers, specifically the listener-vtable population that
AUDIT-016 traced to `[0x40ba9a80+0]` containing the dispatch table. With
AUDIT-024A's falsification of `[+64]==-1` as the blocker (canary has
`+64==0` even when audio is firing), look for what kernel call writes
the LISTENER's vtable in canary; cross-reference against our canary-only
export queue (`ExTerminateThread`, `KeReleaseSemaphore`,
`XamUserReadProfileSettings` are all consequences not causes — the
cause is upstream).
(B) **Audio worker host-thread emulation**: complete mirror of canary's
`AudioSystem::WorkerThreadMain` (semaphore.Release `queued_frames` times
on RegisterClient + drive callbacks from a host thread). Risk: lockstep
determinism unless quantized to instruction-count.
(C) **Audio-side workaround**: keep `--xaudio-tick` opt-in; not recommended.
## Trace artifacts
- `audit-runs/audit-025-audio-thread-start/probe.log` (CTOR-PROBE + dispatcher dump)
- `audit-runs/audit-025-audio-thread-start/probe.err` (counters + thread states)
- (pre-existing) `audit-runs/audit-024a-canary-diff/ours-dump.{log,err}`
- (pre-existing) canary `/home/fabi/xenia_canary_windows/xenia.log` lines 1527-1606
## Cleanup
No source modified. xenia-rs master HEAD `de5a15e` unchanged from Path 2's
merge. No commit produced this session.

232
migration/claude-memory/project_xenia_rs_audit_027_v40_mem_diff_2026_05_08.md Normal file
View File

@@ -0,0 +1,232 @@
# KRNBUG-AUDIT-027 — v40 heap memory diff vs canary (READ-ONLY, 2026-05-08)
Master HEAD at start/end: `e061e21`. NO source modified, NO commit.
## Executive summary
Comprehensive byte-level dword diff between canary's existing 248.6 MiB
memory dump (audit-024A, captured at first `XAudioSubmitRenderDriverFrame`)
and our impl's runtime memory at the v40000000 heap (1008 MiB span,
base 0x40000000, page size 65536).
Goal: find every dword address where canary stores a `0x82xxxxxx` PC
value that ours does not, then cross-reference with the renderer cluster
L1 PCs (`0x82285000-0x82294000`) to identify any dispatch table base.
**Outcome: NO cluster L1 PC hits in canary's v40 (broad 116-fn set: 0,
narrow 6-fn picks: 0). v40 is structurally NOT the dispatch-table source
either.** Three vtable-shaped runs were detected at `0x40000770` (32 dwords),
`0x400015a0` (110 dwords), and `0x40000d90` (20 dwords) — all populated in
canary, all zero in ours — but their target PCs cluster in `.text` at
`0x8284cxxx`/`0x8284dxxx`/`0x82882xxx` (heap-allocator class + .data
helpers), not in the renderer cluster.
**v40 is the third heap region eliminated as the dispatch-table source
(after v80 in audit-026, `0x828Fxxxx` static .data already known).** The
heap-pointer namespace difference (canary `0xbcXXXXXX` vs ours
`0x40XXXXXX`/`0x4cXXXXXX`) means most direct address comparison at heap
locations is structurally non-comparable.
**Strategic pivot mandatory.** The remaining places a dispatch table
could live are: (a) physical heap (0x20000000 span, 58458 commits in
canary's dump — much larger surface), (b) v00 first 256 MiB (4 KiB pages,
468 commits in canary), or (c) construction at runtime via a
register-passed pointer that never lands in heap memory. Recommend
tracing-based or vtable-write-tap approach next — see directions below.
## Workflow
### Step 1 — Capture our v40
```
cargo run --release -p xenia-app -- exec sylpheed.iso \
--halt-on-deadlock --quiet \
--dump-section=0x40000000:0x3F000000:audit-runs/audit-027-v40-mem-diff/ours-v40.bin \
-n 500000000
# Output: dump-section: wrote 1056964608 bytes from 0x40000000
# (60119 committed pages) to ours-v40.bin
```
Note `-n 500_000_000` (with underscores) is rejected by clap; use plain digits.
### Step 2 — Extract canary's v40
`audit-runs/audit-027-v40-mem-diff/extract_v40.py` (adapted from
audit-026's extract_v80.py — just changes selected heap to v40 + size
0x3F000000). Walks heaps in order (v00 v40 v80 v90 physical) decoding
PageEntry state at qword bits 60-61, copies committed v40 pages into a
1008 MiB buffer.
```
canary v40 page count = 16128, committed = 90
output: canary-v40.bin (1056964608 bytes)
```
(canary's 60119-vs-90 ratio is striking but not buggy — canary uses the
v40 heap minimally; our impl maps significantly more.)
### Step 3 — dword-level diff
`audit-runs/audit-027-v40-mem-diff/diff_v40.py` — same shape as
audit-026's diff_v80.py:
- A-list: canary has `0x82xxxxxx` PC, ours differs (typically zero)
- B-list: ours has `0x82xxxxxx` PC, canary differs
```
case A divergences: 536 (canary has PC, ours zero/different)
case B divergences: 31947 (ours has PC, canary zero/different)
```
## Findings
### Histogram of canary-side PCs (top 10 by count, A-list)
```
0x828f3xxx 90 -- dispatcher area (0x828F3D08 etc., already known .data)
0x8284dxxx 78 -- .text near end of code section (heap-allocator handlers)
0x8284cxxx 64 -- .text near end of code section (heap-allocator handlers)
0x82150xxx 30 -- .text near base
0x828f4xxx 23 -- .data dispatcher / listener-related
0x82882xxx 20 -- .data tables
0x82153xxx 16 -- .text
0x828e2xxx 16 -- .data
0x82151xxx 15 -- .text
0x82870xxx 9 -- .data
```
### Cluster L1 hit count: ZERO
```
broad set (116 functions in 0x82285000-0x82294000): 0 hits
narrow set (6 hand-picked): 0 hits
```
The 9 PCs in the broader 0x822xxxxx range that DO appear in A-list all
land in `0x822F1xxx-0x822F2xxx` (`sub_822F13B0`, `sub_822F1AA8`,
`sub_822F17F0`, `sub_822F1F20`) — this is exactly the **main frame-poll
function from audit-009**, and these are stack-frame return addresses,
not dispatch-table entries. Located in `0x70xxxxxx` pages = guest stack
region.
### Three vtable-shaped runs
| base | length | shape |
|------------|--------|----------------------------------------------------------|
| 0x40000770 | 32 | starts `0x8284Da50, 0x8284Da60, 0x8284Da70, 0x825FB958` |
| 0x400015a0 | 110 | identical first 32 entries to 0x40000770 |
| 0x40000d90 | 20 | `0x82882910, 30, 50, 70, 90, b0, ...` (consecutive +0x20)|
**Header pattern preceding 0x40000770 (at +0x760):**
`00 09 00 0e 00 01 10 00 40 00 01 c8 40 00 01 c8`
**Header pattern preceding 0x400015a0 (at +0x1590):**
`00 21 00 81 00 01 10 00 40 00 01 80 40 00 01 80`
The repeated `40 00 01 XX` self-pointer pair is characteristic of a
heap-allocator block descriptor (begin/end of an STL vector / linked
list). The two table instances are different objects of the same C++
class with 110 virtual methods (massive class). Targets in `0x8284cxxx`
land **inside `.text`** (sec ends at `0x8284E2DC`) — these are the
heap-allocator's per-method handler thunks, NOT renderer handlers.
The `0x40000200..0x40000600` region in canary has self-pointer chains
(`40 00 02 00, 40 00 02 00, 40 00 02 08, ...`) — canary's BaseHeap
free-list intrusive metadata. Ours has those addresses zero (different
allocator strategy).
### Listener struct cross-reference (0x40BA9A80)
```
canary 0x40BA9A80: ALL ZERO (page uncommitted in canary's dump)
ours 0x40BA9A80: 40 11 18 90 +0x10=03 e8 +0x14=01 00 00 00 ...
+0x2C=40 24 ac 00 +0x3C=40 24 b3 e0
```
Canary's listener lives at a different heap address (the `0x4..A9A80`
neighborhood is canary-uncommitted). Audit-016's identification of
`0x40BA9A80` as "the listener" was an OURS-side runtime lookup, not a
canary-binding location. The listener allocation is **heap-pointer
divergent** between runtimes — not a missing-write.
### B-list (ours-only PCs)
31947 entries. Cluster L1 PCs found in OURS at v40 heap addresses where
canary is uncommitted: 104 entries. These are in `0x42xxxxxx`,
`0x44xxxxxx`, `0x4Cxxxxxx`, `0x4Dxxxxxx` ranges — heap addresses canary
doesn't allocate. Distribution:
```
0x4b9xxxxx 12645 -- ours stack/locals area (e.g. repeated 0x82026068, 0x8202670c)
0x402xxxxx 2451 -- vtable-arrays our impl writes (interesting!)
0x4cf-0x4d2 6786 -- ours heap arenas canary doesn't use
```
`0x40211900..0x40211B50` has `0x82183ae8, 0x82187e38, 0x8218cf10,
0x82191b18, 0x821958c8, 0x82197448, 0x82199600, 0x821a3a50, 0x821ac770,
0x821b0378, 0x821b41f0, 0x821b7178, 0x821ba1c8, ...` = 23 consecutive
function entries spaced 0x20 apart. **THIS is a vtable our impl
constructs but canary may construct elsewhere** — addresses canary
DOESN'T have at all in v40 means canary's instance is allocated
in a different heap (likely physical, 58458 commits).
## Bug-class classification
**Outcome (iii): v40 ELIMINATED as dispatch-table source.**
Combined with audit-026's elimination of v80, two of the four guest-virt
heap regions are conclusively non-sources for the renderer cluster's
dispatch tables. Remaining surface:
1. **physical heap** (0x20000000 span, 58458 commits in canary) — by far
the most likely. Vtable-arrays our impl puts in `0x402xxxxx` likely
correspond to canary's physical-heap allocations.
2. **v00 heap** (256 MiB, 4 KiB pages, 468 commits in canary) — small
but non-zero.
3. **register-only / stack** — vtable-pointer constructed at runtime and
never landed in heap memory.
## Discipline gate
- Box 1 (canary citation): N/A — pure-data audit.
- Box 3 (probe-confirmed reachability): N/A — no fix proposed.
- This is a strategic-elimination diagnostic.
## Sharp next-session direction
(i) **Recommended: extract canary's PHYSICAL heap (0x20000000 span)** —
same script with `physical` selected. 58458 committed pages =
228 MiB. This is the largest non-static surface and the most
likely home for dispatch tables.
(ii) Alternatively, **vtable-write-tap**: instrument our memory write
path to log every `0x82xxxxxx` value written to v40/physical heap,
and diff against canary log of equivalent. Would directly identify
our missing writes without any address-namespace ambiguity.
(iii) **CPPBUG-AUDIT-001 backlog** — `nt_allocate_virtual_memory`
silent-success-on-error + `mm_allocate_physical_memory_ex` ignores
alignment/range/protect. If we miscompute physical-heap addresses
due to allocator mismatch, that explains the heap-pointer
namespace divergence and could mask the dispatch-table writes.
## Trace artifacts
- `audit-runs/audit-027-v40-mem-diff/canary-v40.bin` (1056964608 bytes)
- `audit-runs/audit-027-v40-mem-diff/ours-v40.bin` (1056964608 bytes)
- `audit-runs/audit-027-v40-mem-diff/extract_v40.py`
- `audit-runs/audit-027-v40-mem-diff/diff_v40.py`
- `audit-runs/audit-027-v40-mem-diff/diff.txt` (536 entries)
- `audit-runs/audit-027-v40-mem-diff/diff-b.txt` (31947 entries)
- `audit-runs/audit-027-v40-mem-diff/histogram.txt`
- `audit-runs/audit-027-v40-mem-diff/l1-hits.txt` (header + 0/0)
- `audit-runs/audit-027-v40-mem-diff/tables.txt` (4 runs >=4)
- `audit-runs/audit-027-v40-mem-diff/pages.txt` (12 pages with diffs)
- `audit-runs/audit-027-v40-mem-diff/anchors.txt` (0x40BA9A80 empty)
- `audit-runs/audit-027-v40-mem-diff/cluster_l1_pcs.txt` (116 fns)
- `audit-runs/audit-027-v40-mem-diff/ours.log`
- `audit-runs/audit-027-v40-mem-diff/diff_run.log`
## Cleanup
No source modified. Master xenia-rs HEAD `e061e21` unchanged. Sister
session 028 untouched.

158
migration/claude-memory/project_xenia_rs_audit_028_steady_state_notify_2026_05_06.md Normal file
View File

@@ -0,0 +1,158 @@
# KRNBUG-AUDIT-028 — XNotify Steady-State Notification Audit
**Date**: 2026-05-08 (per env)
**Mode**: READ-ONLY canary log + canary source analysis
**Master HEAD**: `e061e21` (unchanged)
**Tests**: 605 (unchanged)
**Lockstep**: instructions=100000003 (unchanged)
## Goal
Determine whether canary delivers MORE XNotify notifications during the
steady-state audio-frame loop than the 4 startup notifications IO-004
already wired up. Per AUDIT-009, our main thread polls `XNotifyGetNext`
1.49M times forever. If canary delivers steady-state notifications we
don't, those would be the missing wake source.
## Canary log oracles
- `/home/fabi/xenia_canary_windows/xenia.log` — 5260 lines, 348 KB
(Windows shorter run)
- `/home/fabi/RE Project Sylpheed/xenia-rs/audit-runs/audit-024a-canary-diff/canary.log`
— 17245 lines, 1.27 MB (Linux Debug, deeper steady-state)
`log_level=2 log_mask=0` in both. `XNotifyGetNext` is declared
`kHighFrequency` at `xam_notify.cc:96` so its CALLS are log-suppressed,
but `XamNotifyCreateListener` and `XNotifyPositionUI` ARE logged.
## Findings
### F1 — Canary's notify-API call timeline (full log)
In the deeper canary log (17245 lines):
| Line | Call |
|-------|---------------------------------------------|
| 1347 | `XamNotifyCreateListener(0x2F, 0x00000000)` |
| 2018 | `XNotifyPositionUI(0x0A)` |
**That's it.** No further notification-API mentions for the remaining
~15000 lines of steady-state activity.
### F2 — Canary IS in steady-state
Tail of the log shows active per-frame work:
- `KeReleaseSemaphore(0x828A3230, 1, 1, 0)` — 2224 occurrences
(audio buffer-completion sema, hammered by tid `F8000074`)
- `XamInputGetCapabilities` — main thread (`F8000008`) polls all 4
slots in tight loop until log end
- GPU `01000010` actively makes textures coherent + loads new tiled
textures + `VdRetrainEDRAM`
- `VdSwap` count = **1** in canary (just the export-table TOC entry —
ZERO actual swap calls logged through 17245 lines)
So canary is busy in steady-state AND swaps are ALSO not happening
yet — our impl's swaps=2 is actually AHEAD of canary's frame counter.
### F3 — All canary BroadcastNotification publishers (34 sites, 11 files)
`grep -rn "BroadcastNotification\|PostNotification" --include='*.cc'`
in `/home/fabi/RE Project Sylpheed/xenia-canary/src/xenia/`:
- `kernel_state.cc:1046` — `BroadcastNotification` impl (fans out to
all listeners)
- `kernel_state.cc:1022-1031` — startup-only enqueue (4 IDs we match)
- `xam_notify.cc:111` — `XNotifyBroadcast` shim (game-callable)
- `emulator.cc:940` — `kXNotificationLiveContentInstalled` on
`InstallContentPackage` (UI-driven)
- `emulator_window.cc:1572-1605` — UI menu actions (host UI only)
- `xam_ui.cc` x16 — menu/UI open/close events (host UI only)
- `xam_user.cc:386-389` — `kXNotificationFriendsPresenceChanged` /
`SystemAvatarChanged` on profile change
- `profile_manager.cc:307-338` — `SystemSignInChanged` on
add/delete/login profile (UI-driven)
- `apps/xmp_app.cc` x4 — XMP playlist play/stop/state-change
(game-callable via `XMPPlay*` paths only)
- `audio_media_player.cc:497` — `XmpStateChanged` on state-change
(only triggered if game plays XMP)
- `smc.cc:61` — `SystemTrayStateChanged` on disc-tray eject (SMC)
- `gamercard_ui.cc:672` — gamercard UI close (host UI only)
- `input_system.cc:69` — `SystemInputDevicesChanged` on controller
hotplug (only on slot connect/disconnect EDGE)
**No publisher fires every frame, every audio buffer, or in any
implicit boot-time periodic.** All publishers are event-driven from
host UI, profile/XMP/UI menu, or hardware hotplug edges.
### F4 — Canary's host-side controller hotplug check
`input_system.h:66-68` defines the log message
`"Controller disconnected from slot {}." / "New controller connected
to slot {}."`. **Neither phrase appears in canary's log** — so no
controller hotplug fired in this run. (Sylpheed launches in
controller-pre-connected state.)
## Outcome classification: β (XNotify is NOT the gate)
Canary delivers ZERO additional XNotify notifications past the 4
startup ones during the relevant boot/audio-frame window. Our impl
already matches canary's notification timeline byte-for-byte (4
startup IDs on first listener with `mask & kXNotifySystem |
kXNotifyLive`, per IO-004).
The 1.49M `XNotifyGetNext` polls in our main thread are exactly
mirrored in canary — both are dutiful idle polling that's part of
the game's own poll loop, NOT a missing-publisher symptom.
## Strategic pivot — XNotify queue is closed
The audio/render gate is NOT a missing notification. It's still the
γ-cluster from AUDIT-009/016/017/025: the renderer's per-frame
audio-update path (`sub_824D23B0` invoked via vtable on the
audio_system object at `[r31+0]=0x82006CF4`) is unreached because
the renderer cluster `0x82287000-0x82294000` is itself unreached.
Cross-cutting: AUDIT-027 sister session is investigating the v40
heap memory diff which may reveal whether the renderer's listener-
vtable registry is unpopulated (audit-016's "vtable-registry-not-
populated" hypothesis).
## Recommended next session
**AUDIT-029**: pivot back to the renderer-cluster root cause per
AUDIT-025's option (A): "what kernel call materializes the listener-
dispatch table so renderer can route per-frame audio." Specific
sub-tasks:
1. Probe-set the L1 callers of the unreached cluster:
`sub_82293448, sub_822919C8, sub_82288028, sub_82292d80,
sub_822851e0, sub_82286bc8` (per AUDIT-009).
2. Static-grep canary source for code that populates the
`0x82006CF4` audio_system vtable at runtime — likely
`XAudioRegisterRenderDriverClient` / `AudioSystem` init
shim writing the function-pointer table.
3. Diff that population path vs our impl. Likely a missing `stw`
to a known guest-memory address that holds the dispatch
function pointer.
Sharp 4-dim cascade prediction (provisional):
- A: one of audit-009 cluster L1 PCs starts firing.
- B: `KeReleaseSemaphore(0x828A3230)` count goes from 0 to many.
- C: `XAudioSubmitRenderDriverFrame` count goes from 0 to many.
- D: `VdSwap` count climbs (currently 2 in our impl, 1 in canary).
## Trace artifacts
- This memory file.
- Audit dir: `audit-runs/audit-028-steady-state-notify/` (created;
no probes — pure analysis).
## Discipline gate
- Box 1 (canary log oracle): PASS (cited line numbers).
- Box 2 (canary source citation): PASS (file:line for all 34 sites).
- Box 3 (runtime PC-probe): N/A (read-only outcome β; no fix).
- Box 4 (4-dim cascade): provisional only (AUDIT-029 not this).
- Box 5 (no source mods): PASS.
No source modified. No commit. Master HEAD `e061e21` unchanged.

163
migration/claude-memory/project_xenia_rs_audit_029_physical_mem_diff_2026_05_08.md Normal file
View File

@@ -0,0 +1,163 @@
# KRNBUG-AUDIT-029 — Physical-Heap Memory Diff vs Canary
**Date**: 2026-05-08
**Mode**: READ-ONLY DIAGNOSTIC
**Master HEAD**: `e061e21` (unchanged)
**Lockstep**: instructions=100000003, imports=987516 (preserved — no source touched)
**Tests**: 605 (unchanged)
## Goal
Comprehensive byte-level diff between canary's physical heap (extracted from
audit-024A's 248.6 MiB `canary-memory.dump`) and our impl's putative physical
region. Final guest-memory surface unaccounted for after audit-024A (v00),
audit-026 (v80), audit-027 (v40), and v90 (no commits).
## Method
1. Tried dumping our `0xA0000000:0x20000000` (uncached alias).
2. Tried dumping our `0xE0000000:0x20000000` (cached alias).
3. Tried dumping our `0x00000000:0x20000000` (raw flat physical addr).
4. Extracted canary's physical heap via `extract_physical.py` (5th heap,
4096-byte pages, state at qword bits 60-61 — same format as audit-026/027).
5. Walked all 0x82xxxxxx PC dwords on canary's physical heap,
cross-referenced with cluster L1 sets, audit-017 chain, and v40 table.
## Architectural finding (NEW)
**Our impl has no separate physical heap.** All three of our alias dumps
returned `0 committed pages`. `MmAllocatePhysicalMemoryEx` (exports.rs:644-676)
calls `state.heap_alloc()` (state.rs:702-720), a single bump allocator at
`heap_cursor` starting at `0x40000000`, shared with `NtAllocateVirtualMemory`.
Canary, by contrast, has a dedicated 512MB physical pool (memory.cc:222-242)
accessible via 0xA0/0xC0/0xE0 aliases with byte ID-mapping `& 0x1FFF_FFFF`
to host membase offset 0..0x20000000.
`translate_physical()` in `crates/xenia-memory/src/heap.rs:226-229` masks
`& 0x1FFF_FFFF` and adds to membase, but our heap_cursor never allocates
into 0..0x20000000 — that range only holds the static XEX image and is
never written by `MmAllocatePhysicalMemoryEx`. Result: physical aliases
decode to uncommitted pages.
This is a non-bug architectural divergence (both impls correctly serve
guest reads/writes), but it means canary's 228 MiB of heap data lives at
physical addresses while ours lives at 0x40xxxxxx virtual addresses.
## Canary physical heap (extracted)
- File: `canary-physical.bin`, 512 MiB, 24.5 MiB non-zero (4.5%).
- Committed pages: **58458** × 4096 ≈ 228 MiB.
- Total parsed = 0xf895800 = file size (clean walk).
- 0x82xxxxxx PC dword density: **28851** dwords across 4467 4K pages
(536 64K-aligned regions).
## Diff results
### Cluster L1 PC hits
- Narrow audit-009 hand-picked 6 (`sub_822919C8`, `sub_82293448`,
`sub_82288028`, `sub_82292D80`, `sub_822851E0`, `sub_82286BC8`):
**0 / 6 hits.**
- Broad 116-fn cluster set: **2 / 116 hits.**
- `sub_8228CC18` at phys 0x1330d620 — scalar, not in any table.
- `sub_8228A220` at phys 0x1351ef2c — scalar, not in any table.
### Audit-017 chain PC hits
`sub_82184318`, `0x82184374` (writer), `sub_82187768`, `sub_82187dd0`,
`sub_82183ca8`, `sub_822919c8`, `sub_82186760`, `sub_821c88d0`:
**0 / 8 hits.**
### v40-table cross-reference (CONFIRMS audit-027)
Our 18 PCs at `0x40211900..0x40211B50` (audit-017 chain family,
0x20 stride) appear verbatim on canary's physical heap at
`0x1c32c910..0x1c32cb50` — **identical 0x20 stride, identical 18
PCs, identical trailing dup of `0x821c09d8`**.
This proves the v40 table is `MmAllocatePhysicalMemoryEx`-allocated
in canary; our impl correctly builds the same table but at a v40
virtual address (because of the unified bump allocator). **Table
contents are correct.**
### Top dispatch-shaped runs (≥4 consecutive PC dwords)
| Phys addr | Length | Family | Notes |
|---------------|-------:|-------------------|-----------------------------|
| 0x1e568f38 | 232 | 0x824b0xxx-0x824b2xxx | XAM/UI dispatch (~220 PCs in 0x824b family total) |
| 0x1e6290f0 | 9 | mixed | |
| 0x1c22c9b0 | 4 | mixed | |
| 0x1ce24bc0 | 4 | mixed | |
| 0x1ce254c0 | 4 | mixed | |
### Top PC bucket
`0x82026000` × 12655 occurrences — likely a vtable pointer for a
high-cardinality object array. Region `0x144x0000` shows stride-0x38
entries each containing `0x820266a4` as a vtable slot (per-object,
not dispatch-table).
## Outcome: ζ — ALL FOUR GUEST HEAPS ELIMINATED
**No L1 PCs are stored as data on any heap.** Cluster L1 functions
(`sub_822919C8` etc.) are invoked exclusively via static `bl`
instructions in unreached parent code — they are NOT routed through
a runtime-built dispatch table. Audit-017 chain PCs are likewise
absent from all heap data.
This refutes the entire family of "kernel call materializes a
function-pointer table" hypotheses (audits 010, 011, 012, 015, 016,
017, 026, 027, 029). The renderer cluster 0x82287000-0x82294000 is
unreached because **its static caller chain is not entered**, not
because its dispatch table is not built.
Discipline gate fails box 1 (no fix candidate this session).
## Strategic pivot — AUDIT-030
All vtable/dispatch-table hypotheses are exhausted. The gate is
**upstream of any heap data structure** — a control-flow gate, not
a data-population gate. Two viable approaches:
**Option A (preferred): comparative-execution divergence trace.**
Instrument both runtimes to emit a deterministic event stream
(e.g., `tid:pc:lr:opcode-class` per N instructions) and `diff` to
find the first divergent guest instruction. Lockstep determinism on
our side + canary already patched for `--memory_dump_path` (audit-023,
024) makes a one-more-patch periodic execution sample feasible.
**Option B: targeted canary trace of audio-thread wake-source.**
Per AUDIT-025, `sub_824D23B0` (sole `KeSetEvent(0x828A3254)` caller)
has zero static call-xrefs — invoked only via `[r31+0]=0x82006CF4`
audio_system vtable, which IS populated in our impl (AUDIT-026
byte-identical). The caller must be a per-frame renderer routine
already in our binary. Patch canary to log `LR` on every entry to
`sub_824D23B0`, cross-reference with our PC trace to find which
renderer-cluster function fires in canary but not ours.
**Option C (background backlog):** CPPBUG-AUDIT-001 items.
## Sharp prediction (provisional, low confidence)
First divergence likely a control-flow branch in 0x82200000-0x82290000
whose predicate reads guest memory populated by either a stub-success
kernel export or a hardware-state poll. Candidates:
- An audio_system field beyond the vtable at `0x82006CF4` (AUDIT-026
verified vtable bytes; subsequent fields may differ).
- A GPU/EDRAM-ready / DMA-channel-idle hardware poll stubbed by us.
- A frame-counter / vsync flag advanced differently.
## Trace artifacts
Audit dir: `xenia-rs/audit-runs/audit-029-physical-mem-diff/`
- `canary-physical.bin` — 512 MiB extracted heap (24.5 MiB non-zero)
- `ours-physical-A.bin`, `ours-physical-E.bin`, `ours-physical-flat.bin`
— all 512 MiB, all zero (alias not mapped in our impl)
- `extract_physical.py` — heap extractor
- `diff_physical.py` — one-sided PC enumeration
- `diff.txt`, `histogram.txt`, `l1-hits.txt`, `audit017-hits.txt`,
`v40table-hits.txt`, `tables.txt`, `pages.txt`, `pc-summary.txt`,
`cluster_l1_pcs.txt`
## Cleanup
- No source modified.
- No commit; master xenia-rs HEAD `e061e21` unchanged.
- Tests 605 (unchanged), lockstep instructions=100000003 preserved.
## Milestone status
- swaps=2 draws=0 plateau intact.
- 4/4 major guest-memory heaps eliminated as gate carriers.
- All 9 vtable/dispatch-table hypotheses (audits 010-029) refuted.
- Strategic pivot from data-driven to control-flow-driven diagnostics
is now mandatory. AUDIT-030 = comparative execution trace.

127
migration/claude-memory/project_xenia_rs_audit_031_audio_wait_site_2026_05_08.md Normal file
View File

@@ -0,0 +1,127 @@
# KRNBUG-AUDIT-031 — Audio worker wait-site canary trace (2026-05-08)
## Status: READ-ONLY — canary patch reverted at session close
Master HEAD `e061e21` unchanged. Canary `git status` clean (working tree).
## Summary
Outcome **(a)** — canary's audio worker DOES execute PC `0x824D28D0` (the post-wait PC where our tid=9 parks), woken on a hot loop. Wake-source caller identified.
Furthermore, AUDIT-025/-030's static-attribution `sub_824D23B0` as "the only wake-source"
is **mis-attribution** — IDA-DB function-boundary inference for `sub_824D23B0` (claimed range
`0x824D23B0..0x824D2878`, but it actually contains a SECOND function starting at `0x824D29F0`)
fused two distinct functions. The real wake-source is `sub_824D29F0` (no IDA-DB function header,
reached via tail-jump from a thunk at `0x824D6640`, registered at `sub_824D2C08+0x374`).
## Setup
Re-applied audit-030's canary patch (30 LOC across 4 files: `cpu_flags.{cc,h}`, `ppc_hir_builder.cc`,
`x64_emitter.cc`). Patch single-PC (`DEFINE_uint64 log_lr_on_pc`); 4 sequential probe runs.
Used pre-built Debug binary at `build/bin/Linux/Debug/xenia_canary` (audit-030 leftover; reverted
SOURCES still emit it because the binary is stale-but-compatible). The freshly-rebuilt Checked
binary `build/bin/Linux/Checked/xenia_canary` failed to boot in this environment with
"A0000000 range in use by some other system DLL" — Linux build-config drift between Checked and Debug.
Cleaned residual `/dev/shm/xenia_*` files (~100 MB code-cache shm leaks) before each canary run.
## Probes
All probes 25-30s each:
1. `--log_lr_on_pc=0x824D2878` (audio worker entry): 1 fire, tid=`F8000070`, lr=`0xBCBCBCBC` (top-of-thread).
2. `--log_lr_on_pc=0x824D28D0` (post-wait PC): **54,128 fires** in ~5 min, tid=`F8000074`. Confirms wait IS being woken in canary.
3. `--log_lr_on_pc=0x8284DDDC` (KeSetEvent guest thunk, ordinal `0x9D`): 8906 fires. **Critical capture**:
`tid=0100001C lr=0x824D2A44 r3=0x828A3254 r4=1 r5=0` — this names the wake source.
4. `--log_lr_on_pc=0x824D23B0` (sub_824D23B0 entry per IDA): **0 fires** — function entry never executed.
## Wake-source identification
PC `0x824D2A40 bl 0x8284DDDC` = `KeSetEvent(0x828A3254, 1, 0)`. Per `xrefs` table, this is
inside function reached via the FUSED label `sub_824D23B0+0x690` — but there's a second prologue
at `0x824D29F0` (`mfspr r12, LR; bl 0x825F0F88; stwu r1, -192(r1)`), making this a separate function.
Static reachability of `sub_824D29F0` (xrefs table):
- `0x824D6648 b 0x824D29F0` (kind=`j`, tail-jump from a 12-byte thunk at `0x824D6640`)
- `0x824D6640` is referenced as DATA at `sub_824D2C08+0x374` (kind=`ref`, instruction=`addi`).
At PC `0x824D2F7C: addi r4, r10, 26176` (=`r4 = 0x824D6640`); next instructions load r3
from `[r31][68]`, dereference vtable[7] (`[[r3]+28]`), call `bcctrl 20,lt` → registers
the thunk address `0x824D6640` as a callback on whatever object r31 points to.
So: in canary, after `sub_824D2C08` registers the callback at +0x374, something invokes that
thunk periodically — likely a per-frame audio update or VBLANK. The thunk loads
`r3 = [0x828A3264]` (the audio-engine context pointer) and tail-jumps into `sub_824D29F0`,
which runs through to `KeSetEvent(0x828A3254, 1, 0)` at `+0x50`, waking the audio worker.
## Our impl behavior at the same PC
Final-state diagnostic from `xenia-rs exec sylpheed.iso --halt-on-deadlock -n 500000000`:
```
hw=4 idx=0 tid=9 state=Blocked(WaitAny { handles: [2190094932], deadline: None })
pc=0x824d28d0 lr=0x824d28d0 sp=0x71387e80
```
`2190094932 = 0x828A3254`. tid=9 is parked at the post-wait PC, exactly matching AUDIT-025.
Branch-probe verification (`--branch-probe=0x824D2878,0x824D2880,0x824D2884,0x824D2890,0x824D289C,0x824D28A0,0x824D28D0,0x824D28E4,0x824D2904,0x824D2928`):
- `0x824D2878` fires once (entry, cycle 0)
- `0x824D2880` fires once (cycle 9, immediately after `bl 0x825F0F84` save-helper return)
- All later PCs: 0 fires
So tid=9 enters once, hits the prologue, falls through to the wait at `0x824D28CC bl 0x8284DDCC`
(KeWaitForSingleObject), and parks. The `--pc-probe`/`--branch-probe` instrumentation only fires
when the PC is actually executed, not when a thread is dwelling at it post-wait return — so the
"0 fires" at 0x824D28D0 is consistent with parking BEFORE that PC's first execution (tid=9 is
suspended INSIDE KeWait). When/if KeWait returns with success, 0x824D28D0 would fire.
## Bug-class
**γ-deep, vtable-driven** (unchanged from AUDIT-025) — but now with the correct wake-source target
identified. The wake function `sub_824D29F0` is reached via:
1. Object at `[0x828A3264]` (the audio-engine context, r31 in `sub_824D2C08`) has a `vtable[7]`
"register-callback" method.
2. `sub_824D2C08+0x374` calls it with the thunk address `0x824D6640`.
3. Some host/guest scheduler periodically dispatches that callback per audio frame.
In our impl, step 3 is what's missing. Per AUDIT-025, `sub_824D2C08` runs to completion (so step 2
fires). The host-side dispatch loop that should periodically invoke `0x824D6640` is the unreached
gate. This aligns with the broader unreached-renderer-cluster picture in AUDIT-009/-016/-017.
## Sharp next-session prediction (AUDIT-032)
Trace what dispatches the registered callback in canary:
1. Probe `0x824D6640` directly (`--log_lr_on_pc=0x824D6640`) in canary. Capture lr — names the dispatcher.
2. Probe `sub_824D2F7C` (the `addi r4, ...,26176` callsite) and adjacent `bcctrl` at `0x824D2F90`
in canary to capture r3 + the vtable pointer being invoked. r3 names the audio-engine "this",
and `[r3]+28` names the vtable[7] entry.
3. Walk r3's vtable[7] target in the DB. If that target is in our IDA DB but unreached, that's the
new probe target for the renderer/scheduler that should periodically invoke registered callbacks.
4. Cross-check that `sub_824D29F0` is reached in our impl after a fix to step 3.
Predicted outcome: dispatcher is part of the same `0x82287000-0x82294000` cluster identified by
AUDIT-009/-016/-017 as unreached. If true, then audio-thread wake gate IS the renderer gate; same
γ-cluster blocker; but now with a NAMED downstream witness (`sub_824D29F0` callable proves the
dispatcher ran) instead of the indirect handle-signal proxy.
## Files
- Memory: this file
- Trace logs: `/home/fabi/RE Project Sylpheed/xenia-rs/audit-runs/audit-031-wait-site/`
- `canary-0x824D2878.log` (1 trace)
- `canary-0x824D28D0.log` (54128 traces)
- `canary-KeSetEvent.log` (8906 traces, contains wake-source capture)
- `canary-sub23B0.log` (0 traces — falsifies sub_824D23B0 reachability)
## Discipline gate
- Box 1 (canary citation): PASS — direct trace + xrefs table cited
- Box 2 (β/γ class identified): PASS — γ-deep, vtable-driven dispatcher
- Box 3 (probe machinery sane): PASS — 4 separate canary probes consistent
- Box 4 (sharp prediction): PASS — AUDIT-032 has 4-step concrete plan
- Box 5 (no fix attempt): PASS — read-only
Hand-off: AUDIT-032 (canary probe of `0x824D6640` + sub_824D2F7C/F90 with `--log_lr_on_pc`,
walk vtable[7] target, cross-reference with AUDIT-009 cluster).

52
migration/claude-memory/project_xenia_rs_audit_032_audio_host_pump_2026_05_08.md Normal file
View File

@@ -0,0 +1,52 @@
---
name: AUDIT-032 audio is host-pumped + audit-025 revision (2026-05-08)
description: Decisive correction — audio gate is NOT the renderer gate (revising audit-025). Canary uses a host-side WorkerThreadMain that calls processor->Execute on the registered guest callback directly. The 0x824D6640 thunk is the callback_ptr arg, not a vtable[7] entry. 7 prior sessions (018/KE-001/024A/025/026/030/031) chased an audio gate while the renderer plateau remained the independent draws=0 blocker.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-032 (2026-05-08, READ-ONLY, master `e061e21` unchanged)**: re-applied audit-030's `--log_lr_on_pc` patch with PC `0x824D6640` (the thunk audit-031 named as the renderer→audio dispatcher). 7,875 captures in 40s in canary's "Audio Worker (0100001C)" thread.
## The decisive observation
LR is invariant `0xBCBCBCBC` — canary's host stack-canary fill, NOT a valid PPC PC. Canary's `xe::apu::AudioSystem::Setup()` (`xenia-canary/src/xenia/apu/audio_system.cc:84-95`) spawns an `XHostThread` "Audio Worker" running `WorkerThreadMain()`. The loop blocks on `WaitAny(client_semaphores_)`; on wake, calls `processor_->Execute(thread_state, callback_pc=0x824D6640, args)` directly — invoking the guest callback **without a guest call site**.
The instruction at `sub_824D2C08+0x374` (`addi r4, r10, 26176`) loads PC `0x824D6640` as the **callback_ptr argument** to `XAudioRegisterRenderDriverClient`, NOT as a vtable[7] entry. Audit-031's "vtable[7] callback registration" inference was wrong.
## Methodology corrections (CRITICAL)
1. **Audit-025's claim "audio gate IS the renderer gate" is REVISED.** They are SEPARATE stalls that happen to share the "host pump missing" symptom for audio. The renderer plateau (audit-009 cluster L1 reachability) is INDEPENDENT and remains the actual `swaps>2 / draws>0` gate.
2. **Seven prior sessions (KRNBUG-018, KRNBUG-KE-001, AUDIT-024A, AUDIT-025, AUDIT-026, AUDIT-030, AUDIT-031) chased an audio gate believing it was the renderer gate.** The fixes that landed (KeResumeThread mirror, XamUserGetSigninState, XNotify listener, etc.) were genuine canary-divergence fixes but did NOT approach `draws > 0`. Future sessions must NOT re-conflate.
3. **Reading-errors ledger stays at 10** (audit-031's "vtable[7]" was a hypothesis, not a static-analysis claim) but methodology pattern adds an entry: **inferring from a stop-on-instruction tracer that something is invoked from a guest call site is unreliable when the actual invocation is host-side**.
## Sharp 4-dim cascade prediction for audio host-pump fix (NOT critical-path)
If implemented (60-120 LOC mirroring canary `apu/audio_system.cc:84-159`):
- A: tid=9 leaves `Blocked(WaitAny [0x828A3254])` on first callback invocation
- B: tid=10 leaves `Blocked(WaitAny [0x828A3230])` on next sema release
- C: `XAudioSubmitRenderDriverFrame` 0→non-zero
- D: `KeReleaseSemaphore` 0→non-zero (closes last canary-only kernel export)
E (open): tid=10's limit=6 sema = audio-frame queue depth, isolated from renderer.
**The audio fix does NOT unblock the renderer plateau.** It's correctness/hygiene cleanup that would close the canary-only export gaps. Audio worker spawn pattern: HOST thread, NOT guest-thread injection (which APUBUG-PRODUCER-001's --xaudio-tick attempted and caused a HW-thread hijack).
## Strategic position reset
| Surface | Status |
|---|---|
| Static .text/.rdata/.data/.idata | Eliminated (audit-020/021) |
| v00/v40/v80/v90/physical heaps | Eliminated as L1-PC-storage (audit-026/027/029) |
| XNotify queue | Eliminated as steady-state gate (audit-028) |
| Static reachability BFS | Sound (VERIFY-A: 0/12 cluster L1 PCs fire in canary) |
| Mem-watch coverage | Sound (VERIFY-B: 12/12 PowerPC store classes hooked) |
| Linux Debug build as oracle | Faithful at kernel-call level (RECONCILE-A); host-presenter divergence is irrelevant to engine analysis (RECONCILE-B) |
| Audio gate | Identified — host-pump missing in our impl; NOT the renderer gate |
| Renderer plateau | Same gate as audit-009/016/017: cluster `0x82287000-0x82294000` L1 callers unreached. All static analysis exhausted. Next probes need new tooling. |
## Recommended next move
Launch the analysis-toolset overhaul planning session. The renderer hunt is blocked on tools we don't yet have — specifically C++/MSVC vtable detection + indirect-dispatch reachability + class-aware probe targeting. The audio fix (KRNBUG-α-007) can land independently as cleanup whenever convenient.
Trace artifacts at `audit-runs/audit-032-dispatcher-lr/`. Memory file `project_xenia_rs_audit_032_dispatcher_lr_2026_05_08.md` (sister-written by the agent). audit-findings.md KRNBUG-AUDIT-032 entry appended. Master HEAD `e061e21` unchanged, tests 605, swaps=2 draws=0 plateau intact.

105
migration/claude-memory/project_xenia_rs_audit_032_dispatcher_lr_2026_05_08.md Normal file
View File

@@ -0,0 +1,105 @@
# KRNBUG-AUDIT-032 — Audio dispatcher LR capture at thunk 0x824D6640 (2026-05-08, READ-ONLY)
## Status
- **Bug class**: δ — audit-031's hypothesis falsified. Outcome δ + α composite.
- **Master HEAD**: `e061e21` unchanged. No xenia-rs source modified. No commit.
- **Canary patch**: re-applied audit-030 `--log_lr_on_pc` patch (30 LOC, 4 files). REVERTED at session end. Canary `git status` clean. Diff archived at `audit-runs/audit-032-dispatcher-lr/canary-patch.diff` (76 lines incl. context).
- **Tests**: 605 (unchanged). Lockstep `instructions=100000003` preserved.
## Method
- Built canary Debug config explicitly (`cmake --build . --config Debug --target xenia_canary`); the multi-config CMake required this — older Debug binary was stale (May 7).
- Single 40-sec capture of canary running sylpheed.iso with `--log_lr_on_pc=0x824D6640 --disable_instruction_infocache=true`. Log size 35,942 lines.
- Verified our impl reachability with `--pc-probe` and `--branch-probe` on `0x824D6640`, `0x824D29F0`, `0x824D2A00`, `0x824D2A20`.
## Key finding — DISPATCHER IS HOST-SIDE, NOT GUEST
**7,875 fires** of PC `0x824D6640`, all from a single thread:
```
i> 00023890 XThread0100001C (4) Stack: 700D0000-700F0000
K> 0100001C XThread::Execute thid 4 (handle=0100001C, 'Audio Worker (0100001C)', native=467FC6C0, <host>)
i> 0100001C TRACE-PC-LR pc=824D6640 lr=BCBCBCBC r3=30063000 r4=00000000 r5=00000000 r6=00000000 r31=00000000 [first call: setup]
i> 0100001C TRACE-PC-LR pc=824D6640 lr=BCBCBCBC r3=30063000 r4=00000001 r5=00001800 r6=BDFBA600 r31=00000000 [×7874: per-frame]
```
LR is **always `0xBCBCBCBC`** = canary's host-thread stack-fill canary value (not a valid PPC PC). r3=`0x30063000` (driver-context ptr for index 0), r4=0|1 (init-vs-tick flag), r5=`0x1800` (frame size 6144 bytes = 1536 stereo s16 samples), r6=`0xBDFBA600` (the registered callback_arg).
The thread is named **"Audio Worker"** with `native=467FC6C0` and is a `<host>`-flagged kernel thread.
## Mechanism — confirmed via canary source
Canary's `xe::apu::AudioSystem` (host C++) at `src/xenia/apu/audio_system.cc:84-95`:
```cpp
worker_thread_ = kernel::object_ref<kernel::XHostThread>(new kernel::XHostThread(
kernel_state, 128 * 1024, 0,
[this]() { WorkerThreadMain(); return 0; },
kernel_state->GetSystemProcess()));
worker_thread_->set_name("Audio Worker");
worker_thread_->Create();
```
`WorkerThreadMain()` (`audio_system.cc:100-159`):
1. Blocks on `WaitAny(wait_handles_, ...)` — array of per-client semaphores released by the AudioDriver backend each time samples are consumed.
2. On wake, reads `clients_[index].callback` and `wrapped_callback_arg`.
3. Calls `processor_->Execute(worker_thread_->thread_state(), client_callback, args, ...)` — invokes the registered callback **directly via the processor**, bypassing any guest call site. The PPC LR remains the host stack canary `0xBCBCBCBC`.
The audio worker thread is **created host-side at `RegisterClient` time** and pumps the registered callback as the audio backend consumes samples.
## Falsifies audit-031 hypothesis
Audit-031 asserted: thunk 0x824D6640 is "registered as vtable[7] callback at sub_824D2C08+0x374" and "sub_824D29F0's body is reached via per-frame guest dispatch". **Falsified**: the registration at sub_824D2C08+0x374 is the `addi r4, r10, 26176` that loads the PC `0x824D6640` into r4 as the **callback_ptr argument to XAudioRegisterRenderDriverClient** (caller's responsibility). Canary's log shows:
```
d> F8000008 XAudioRegisterRenderDriverClient(701CF210(824D6640), BDFBA658(00000000))
```
where `701CF210[0] = 824D6640` is the callback PC and `701CF210[4] = BDFBA600` is the arg.
The thunk 0x824D6640 → tail-jump to sub_824D29F0 → KeSetEvent(0x828A3254) is **invoked by canary's HOST-side AudioSystem worker thread**, not by guest engine code.
## Our impl gap (confirmed by probe)
Our `XAudioRegisterRenderDriverClient` at `crates/xenia-kernel/src/exports.rs:2705-2745`:
- Correctly captures `callback_pc=0x824d6640`, `callback_arg=0x41e9dd5c`, allocates wrapped, returns `driver=0x41550000`.
- Trace: `XAudioRegisterRenderDriverClient: index=0 callback=0x824d6640 arg=0x41e9dd5c wrapped=0x4b9f0000 driver=0x41550000`.
- **No "Audio Worker" host thread is spawned** to pump the callback.
- **No semaphore-release loop** mirrors canary's `client_semaphore->Release(queued_frames_, nullptr)` followed by per-sample-consumption releases from the AudioDriver backend.
Probe results (-n 500M, 50M-instr sanity):
- `--pc-probe=0x824D6640,0x824D29F0,0x824D2A00,0x824D2A20`: **0 CTOR-PROBE fires**.
- `--branch-probe=0x824D6640,0x824D29F0`: **0 BRANCH-PROBE fires**.
- tid=9 (audio-worker tid_9, entry=0x824D2878) parks at `pc=0x824D28D0` waiting on event `0x828A3254` — the wake source that sub_824D29F0 would set. Never woken.
- tid=10 parks at `pc=0x824D2990` waiting on semaphore `0x828A3230` (count=0/limit=6). Never released.
## Bug class & cascade prediction (sharp)
**Class**: δ-α composite — host-side AudioSystem worker thread missing entirely. Specifically:
1. Our `XAudioRegisterRenderDriverClient` does not spawn a host thread that periodically invokes the registered callback PC.
2. Our `XAudioClient` registry has no audio-backend driver that releases the per-client semaphore on sample consumption.
**Sharp prediction for fix session**: implement a host-driven audio pump per canary `apu/audio_system.cc:84-159`. Minimal viable: on first `RegisterClient`, spawn a host XHostThread that loops `[release client_sema; sleep(~10ms); guest_processor.execute(callback_pc, [callback_arg])]`. Cascade prediction:
- A: tid=9 leaves `Blocked(WaitAny [0x828A3254])` on the FIRST callback invocation that runs sub_824D29F0:`KeSetEvent(0x828A3254, 1, 0)`.
- B: tid=10 leaves `Blocked(WaitAny [0x828A3230])` on the next semaphore release inside sub_824D29F0.
- C: `XAudioSubmitRenderDriverFrame` count rises from 0 (currently canary-only export when running our impl) — guest's audio worker now feeds frames back.
- D: `KeReleaseSemaphore` non-zero (canary-only export landed).
- E: open question — does this unblock a **non-audio** consumer? Tid=10's parking on a semaphore at limit=6 (canary's `queued_frames_=6` initial-release) suggests NOT — limit=6 is audio-frame queue depth, isolated. So this fix may resolve audio path but not the broader audit-009 renderer cluster.
The audio gate is NOT the renderer gate (revising audit-025's "audio gate IS the renderer gate" claim). They are **separate stalls** sharing only the symptom of "host pump missing".
## Outcome classification
Per task brief outcomes:
- **δ confirmed**: audit-031's "registered as vtable[7] callback" inference is wrong; sub_824D29F0 is invoked via host-side `processor_->Execute`, not guest bcctrl through audio_system vtable.
- **α partial**: the "caller PC" we sought to walk up is **canary's host C++**, not guest code. There is no guest LR to walk; the divergence is entirely on the kernel-host boundary at `XAudioRegisterRenderDriverClient`.
## Cross-validation note (Linux-derived, kernel-call-faithful per RECONCILE-A)
The capture is from PPC instruction execution (LR=0xBCBCBCBC observed at the thunk's first instruction) — kernel-call-level data, reliable per RECONCILE-A. The mechanism (host AudioSystem worker, processor_->Execute) is canary source code, not Linux-specific.
## Reading-error ledger note
PCs 0x824D6640 and 0x824D29F0 both fall in **gaps in the IDA functions table** (0x824D6640 between sub_824D6570 and sub_824D6650; 0x824D29F0 between sub_824D23B0 and sub_824D2B08). Confirms audit-031's "second prologue inside claimed sub_824D23B0 range" reading-error pattern. No new ledger entry — this is the same boundary cluster.
## Trace artifacts
- `audit-runs/audit-032-dispatcher-lr/canary-patch.diff` (saved diff before revert)
- `audit-runs/audit-032-dispatcher-lr/probe.{log,err}` (our impl, -n 500M)
- `audit-runs/audit-032-dispatcher-lr/probe-sanity.{log,err}` (our impl, -n 50M sanity)
- `audit-runs/audit-032-dispatcher-lr/branchprobe.{log,err}` (branch-probe verification)
- `/tmp/audit-032-canary.log` (canary capture, 35,942 lines, 7,875 LR fires)
## Recommended next session
Implement host-side audio worker per canary `apu/audio_system.cc`. Estimated 60-120 LOC. Predicted to **unblock audio path** (tids 9, 10) and add canary-only kernel exports (KeReleaseSemaphore, possibly XAudioSubmitRenderDriverFrame). Won't fix the audit-009 renderer cluster (separate γ-class blocker). Critically: audit-025's strategic-pivot recommendation back to renderer cluster L1 callers REMAINS the priority for engine progression; the audio fix is **necessary cleanup of canary-only exports** but is unlikely to flip the swaps=2 draws=0 plateau alone.
## Stop conditions honored
- No fix attempted. No xenia-rs source modified. No commit. Canary patch reverted.

96
migration/claude-memory/project_xenia_rs_audit_033_ui_entry_chain_2026_05_08.md Normal file
View File

@@ -0,0 +1,96 @@
# KRNBUG-AUDIT-033 — UI/save-game subsystem entry-chain divergence probe
- Date: 2026-05-08
- Mode: READ-ONLY (canary patch landed + reverted; no xenia-rs source change)
- Master: `9028021` unchanged
- Trace dir: `audit-runs/audit-033-ui-entry-chain/`
## Goal
Identify which PC in the call-chain leading to the UI/save-game
subsystem cluster (`0x82285000-0x82294000`) is the first divergence
between canary and our impl.
## Method
- Re-applied 30-LOC `--log_lr_on_pc` canary patch (audit-030 diff at
`audit-runs/audit-030-lr-trace/canary-patch.diff`). NOTE: build
must use `ninja -f build-Debug.ninja xenia_canary`, not the default
Checked variant (Checked has runtime code-cache allocation collision
that prevents boot reliably).
- Probed 8 PCs in canary, 50s wall each:
- Tier 1 (cluster externals): `0x8228A628`, `0x8228E138`, `0x8228E498`.
- Tier 2 (their callers): `0x82172524`, `0x82175810`, `0x8217EB78`.
- Tier 3 (CMessageBridge sites): `0x821A6CF0`, `0x821A8578`.
- xenia-rs `--pc-probe` of same 8 PCs at -n 500_000_000.
## Results
### Canary (50s boot)
- `0x8228E138`: 2 fires, LR=`0x82172BF8` (in `sub_82172BA0`).
- `0x8228E498`: 28 fires, LRs=`0x82451E78` (in `sub_82451E20`),
`0x82174730` (in `sub_821746B0`).
- All 6 other PCs: 0 fires.
### xenia-rs (-n 500M ≈ 8s guest)
- `0x8228E138`: 1 fire, LR=`0x82172BF8` (same caller as canary).
- `0x8228E498`: 62 fires, LR=`0x82451E78` (same caller as canary).
- All 6 other PCs: 0 fires.
### Frame chain captured by our impl's CTOR-PROBE on 0x8228E498:
```
frame=0 lr=0x82451e78 (sub_82451E20)
frame=1 lr=0x824508c4 (sub_82450720)
frame=2 lr=0x8245065c (sub_82450638)
frame=3 lr=0x821cb9a0 (sub_821CB968)
frame=4 lr=0x821cd54c (sub_821CD458)
frame=5 lr=0x821cbf30 (sub_821CBEA8)
frame=6 lr=0x821ceda0/0x821ceebc (sub_821CECF0)
frame=7 lr=0x821c49f8/0x821c504c (sub_821C4988)
```
## Reading
- **Both implementations enter the cluster** via 2 of 3 Tier-1 externals
with identical LRs. Audit prompt's hypothesis "canary reaches Tier 1
but ours doesn't" is FALSIFIED for sub_8228E138/sub_8228E498.
- **Tier 2 + Tier 3 PCs are 0-fires in canary** at 50s boot — i.e. the
cluster's full activation isn't yet triggered even in canary. The
prompt's claim that CMessageBridge sites "were observed firing in
past audits" is correct, but those past audits ran for longer or at
later boot phases.
- **Frequency divergence on 0x8228E498**: ours 62× / 8s guest vs canary
28× / 50s wall — ours appears to busy-loop the constructor-array
dispatch at sub_82451E20. Either (a) canary breaks out via a state
flag ours never sets, or (b) ours just runs faster through the
same loop and there are actually similar fire counts per guest-time.
Cannot disambiguate without canary's own cycle-counter.
- **Bug class**: γ (deeper-indirection / vtable-driven dispatch). M5
static reachability is blind here per known limitation; M5.5 (this-flow
vptr resolution) is the prerequisite.
## Falsifications (this session)
- Tier 1 PC `0x8228A628`: 0 fires in canary even at 50s — not a live
entry point in this boot phase.
- Tier 2 + Tier 3 callers (`0x82172524`, `0x82175810`, `0x8217EB78`,
`0x821A6CF0`, `0x821A8578`): all 0 fires in canary.
## Discipline gate
| Box | Status |
|-----|--------|
| 1 — both-side probe data | PASS |
| 2 — canary fires Tier 1 | PARTIAL (2 of 3) |
| 3 — cross-impl LR mirror | PASS (LRs match exactly) |
| 4 — bug class assigned | γ — does not gate to fix |
| 5 — no fix this session | PASS |
## Recommendation
- **Primary**: schedule M5.5 (this-flow vptr resolution) as next analyzer
milestone. Without it, top-down probing inside the cluster is blind.
- **Alternative A**: probe the frame-chain inside sub_82451E20 → walk
upstream to find the loop-exit gate (62 vs 28 fires). Probe
`0x82450720`, `0x82450638`, `0x821CB968` next.
- **Alternative B**: longer-horizon canary trace via Lutris Windows
build (5-10 min) to capture post-intro cluster activation. The 50s
Linux Debug envelope is too short for "press-A" boundary.
## Cleanup
- Canary patch reverted; `cd xenia-canary && git status` clean.
- xenia-rs master HEAD `9028021` unchanged.
- No commit, no source modification.

216
migration/claude-memory/project_xenia_rs_audit_034_frame_chain_divergence_2026_05_08.md Normal file
View File

@@ -0,0 +1,216 @@
# KRNBUG-AUDIT-034 — frame-chain divergence + post-intro Tier 2/3 horizon
- Date: 2026-05-09
- Mode: READ-ONLY (canary patch landed + reverted; no xenia-rs source change)
- Master: `9028021` unchanged; tests 640; lockstep instructions=100000003
- Trace dir: `audit-runs/audit-034-frame-chain/`
- Subsystem: front-end UI / save-game / mission-select / HUD (per RAPID-SURVEY-Q4); NOT renderer
## Phase A — Frame-chain divergence probe (50s canary, -n 500M ours)
### Canary patch
Re-applied audit-030 30-LOC `--log_lr_on_pc` patch (4 files: x64_emitter.cc,
cpu_flags.cc, cpu_flags.h, ppc_hir_builder.cc). Linux Debug build via
`ninja -f build-Debug.ninja xenia_canary`. Patch reverted at session close;
canary `git status` clean.
### Firing-rate matrix (raw counts, 50s canary wall vs ours -n 500M = 24.05s wall)
| Level | PC | canary 50s | ours -n 500M (24s wall) |
|-------|----|-----------:|------------------------:|
| L0 (chain top) | sub_821C4988 | 1 | 1 |
| L1 | sub_821CECF0 | 2 | 2 |
| L2 | sub_821CBEA8 | 7 | 7 |
| L3 | sub_821CD458 | 7 | 7 |
| L4 | sub_821CB968 | 14 | 14 |
| L5 | sub_82450638 | 14 | 14 |
| L6 | sub_82450720 | 24 | 16 |
| L7 | sub_82451E20 | 90 | 80 |
**Caveat — wall-time normalization**: ours wall_ms=24049 for 500M instructions
(per `exec complete` line in ours.err); canary 50s wall does an unknown number
of guest instructions (Debug build is ~5-10× slower per wall-second). Per-wall
divergences are distorted by this slowdown. **Per-call ratios (downstream/upstream)
ARE timing-independent** and that's where the real signal lives.
### Per-call ratios (timing-independent)
| Edge (caller→callee) | canary | ours |
|----------------------|-------:|-----:|
| sub_821C4988 → sub_821CECF0 | 2.00 | 2.00 |
| sub_821CECF0 → sub_821CBEA8 | 3.50 | 3.50 |
| sub_821CBEA8 → sub_821CD458 | 1.00 | 1.00 |
| sub_821CD458 → sub_821CB968 | 2.00 | 2.00 |
| sub_821CB968 → sub_82450638 | 1.00 | 1.00 |
| sub_82450638 → sub_82450720 | 24/14=**1.71** | 16/14=**1.14** |
| sub_82450720 → sub_82451E20 | 90/24=**3.75** | 80/16=**5.00** |
(Single-LR sites everywhere; chain identity verified end-to-end.)
### Reading
- **L0..L5 chain shape is IDENTICAL** between canary and ours
(single-LR per site, identical caller-to-callee multipliers). This
falsifies any "chain-shape divergence" hypothesis — both implementations
walk the exact same path from sub_821C4988 down to sub_82450638.
- **L5 → L6 is the first divergence point** (sub_82450638 → sub_82450720
multiplier): canary 1.71, ours 1.14. sub_82450638 has TWO call sites of
sub_82450720 (LR=0x8245065c first, 0x824506cc second). Ours probe shows
14×LR=0x8245065c + 2×LR=0x824506cc = 16. Canary likely 14+10. **Canary
takes the second call path more often** — that path runs after the first
call returns SUCCESS and validates a state condition. Ours typically
fails the gate that triggers the second call.
- **L6 → L7 is the second divergence point** (sub_82450720's 5-iter inner
loop): canary 3.75 avg iters, ours 5.00 (always exhausts). The early-exit
predicate at PC 0x82450904 (`bne 0x8245092C`) is FAILING TO FIRE in ours.
### Loop-exit-divergence PC (Phase A4)
**The diverging loop is sub_82450720+0x160..+0x1F4 (PC 0x82450880..0x82450914).**
Loop body:
```
0x82450880: li r25, 0 # iter counter
0x82450890: lwz r11, 0(r30) # load slot[iter] hi -- r30=r26+108+iter*20
0x824508a0: addi r4, r31, 104 # build cur-key local
0x824508a8: add r9, r9, r11 # cur_sum = lo+hi
0x824508c0: bl sub_82451E20 # find/replace
0x824508c4: lwz r11, 4(r30); lwz r10, 0(r30)
0x824508d8: add r11, r11+r10 # expected sum
0x824508dc: cmpl r29 == r30-12 ? # check sub_82451E20 wrote correct cur-key ptr
0x824508e4: cmpl r28 == sum # check sub_82451E20 wrote correct sum
0x824508f0..0x82450900: bit-extract via cntlzw to {0,1}
0x82450904: bne 0x8245092C # FAILURE -> exit (insert path)
0x82450908: addi r25, 1 # SUCCESS -> next iter
0x8245090c: addi r30, r30, 20 # advance slot ptr
0x82450910: cmpli r25, 5
0x82450914: blt 0x82450890 # loop while r25<5
```
**The exit predicate at 0x82450904 is `bne` on the result of two equality
checks against sub_82451E20's output (r29=[r31+112], r28=[r31+116])**:
- `[sub_82451E20_out+0] == r30-12` (= r26+96+iter*20, the cur-slot stem)
- `[sub_82451E20_out+4] == [r30+0]+[r30+4]` (the slot's lo+hi sum)
**Sub-predicate**: sub_82451E20's exit-loop path picks (r27, r30_local):
- inner loop at 0x82451e60..0x82451eb0 exits via 0x82451e90 (`bne` after
`cntlzw`/`extrwi` of `r28 - [sub_8228E498(working_key)+0][32]`)
- exit when `r28 == [r3+0][32]` (via Tier-1 cluster member sub_8228E498)
- writes (r27, accumulated-r30) back to caller's r3 = r31+112
**The exit predicate's data source is the per-iter slot at r26+108+iter*20**
(r26 = sub_82450720 arg1, an "object" pointer; offset 108..207 = a 5×20-byte
table). Whether the predicate fires depends on whether the slot's
(stem, sum) pair matches what sub_82451E20 produces — which itself depends
on the value at `[sub_8228E498(slot_key)+0][32]` (cluster sub-table data).
### Diagnostic asymmetry — slot-position arithmetic
**sub_82450720 return semantics**:
- early-exit via 0x82450904 → return r3=1 (success)
- exhaust 5 iters via 0x82450914 fall-through → return r3=0 (failure)
**sub_82450638 cascade**:
- first call (LR=0x8245065c): if returned 1 → skip second call, return 1 directly
- if returned 0 → invoke second call (LR=0x824506cc), return its result
**LR distribution observations**:
- canary 0x82450720: 14×first + 10×second = 24 (10 first-calls returned 0)
- ours 0x82450720: 14×first + 2×second = 16 (2 first-calls returned 0)
**Per-call iteration math**:
- canary: 14 first-calls produce ~4 returning 1 + ~10 returning 0; iters
= 4×(k_avg+1) + 10×5 = 90 - 50 = 40 / 4 = avg k+1 = 2.86 →
**canary's early-exit fires at avg iter k≈1.86** (slot 1-2 of 5).
- ours: 14 first + 2 second = 16; 12 first-calls return 1, 4 return 0;
iters = 12×(k+1) + 4×5 = 80 → 12(k+1) = 60 → **k_avg=4 in ours
(last iter of 5)**.
**Key inversion**: ours's 12 successful early-exits all fire at the LAST
iter (index 4) — the 5th slot of 5. canary's 4 successful early-exits
fire at iter 1-2. **The matching slot is at a DIFFERENT POSITION** in
the 5-element table between canary and ours, OR the slot population
order is reversed, OR the search-key hashes to a different slot.
**Bug class**: β-class data-state divergence at slot table r26+108..207
(20-byte stride × 5 slots). The 5-loop always finds a match in BOTH
implementations (predicate is satisfiable both ways), but at very
different positions. This indicates the table CONTENTS differ even
though the lookup logic is identical.
## Phase B — post-intro Tier 2 + Tier 3 horizon (300s canary)
### Probe set
- Tier 2 callers: 0x82172524, 0x82175810, 0x8217EB78
- Tier 3 CMessageBridge: 0x821A6CF0, 0x821A8578
### Result — ALL 5 = 0 FIRES AT 300s
| PC | tier | canary 300s wall |
|----|------|----:|
| 0x82172524 | T2 | 0 |
| 0x82175810 | T2 | 0 |
| 0x8217EB78 | T2 | 0 |
| 0x821A6CF0 | T3 | 0 |
| 0x821A8578 | T3 | 0 |
### Reading
- **Cluster activation is gated even deeper** than this 5-min Linux Debug
canary trace can reach. RECONCILE-A confirms Linux Debug canary trajectory
is identical to Lutris Windows up to frame 42 (vs 72/186 on Lutris); the
300s probe windows we see correspond to early-boot pre-intro behavior
only.
- Audit-033's framing stands: cluster activation is NOT triggered by the
intro→main-menu transition that canary's Linux Debug build reaches. May
need either:
- A Lutris Windows build trace (gets further into intro/menu) for these
PCs, OR
- Probing UPSTREAM of these PCs to find what would call them, OR
- A non-time-based trigger (e.g., specific kernel API or memory state).
## Bug class
**β-class (data-state divergence) with γ-deep entry**:
- Entry to chain (sub_821C4988) is via vtable / indirect dispatch (0 static
call xrefs — γ-deep).
- 6.3× upstream divergence in entry frequency from sub_821C4988 onwards.
- 5-loop early-exit predicate in sub_82450720 reads slot-table data at
r26+108..207 and never matches in ours — full 5-iter scan vs canary's
~3.75-iter avg.
- The Tier-1 cluster external sub_8228E498 is invoked from sub_82451E20's
inner loop: it returns `(table[hash])+offset`, the table index/value
used for the predicate.
## Sharp next-session prediction
The exit predicate's data source is **the 5×20-byte slot table at r26+108**
where r26 = sub_82450720 arg1 = sub_82450638 arg1 = sub_821CB968 arg1 (a
container struct). The slots' (stem, sum) values must match sub_82451E20's
output to trigger early exit.
**AUDIT-035 candidate**: `--mem-watch r26+108..207` for one captured r26
value (capture via `--pc-probe=0x82450720` extended to log r4) to see what
canary writes there during boot vs ours. If canary writes non-zero
slot data and ours has zeros, AUDIT-035 names the writer.
Alternative: probe sub_8228E498 directly (already done in audit-033) — its
output `[r3+0][32]` value is what sub_82451E20 compares against.
## Discipline gate
- 1 milestone declared: AUDIT-034. ✅
- 1 outcome captured: β-data-divergence at sub_82450720's 5-loop. ✅
- 1 sharp next-session prediction: mem-watch r26+108..207. ✅
- ≤2 hours wall: ~17 min Phase A + ~25 min Phase B. ✅
- No xenia-rs source mods, no xenia-rs commit. ✅
## Files
- `audit-runs/audit-034-frame-chain/canary-0x*.log` — 8 canary 50s logs + 1
300s log (preserved as `.300s.log`) + 5 Phase B 300s logs
- `audit-runs/audit-034-frame-chain/ours.log` — single ours -n 500M probe
with 8 PCs
- `audit-runs/audit-034-frame-chain/scripts/probe-canary*.sh` — driver
## Master
xenia-rs HEAD `9028021` unchanged. Tests 640. Lockstep instructions=100000003.
Canary patch reverted; canary `git status` clean.

111
migration/claude-memory/project_xenia_rs_audit_035_slot_table_2026_05_08.md Normal file
View File

@@ -0,0 +1,111 @@
# KRNBUG-AUDIT-035 — slot table byte-level diff at sub_82450720 entry
- Date: 2026-05-09
- Mode: READ-ONLY (canary patch landed + reverted; no xenia-rs source change)
- Master: `9028021` unchanged; tests 640; lockstep instructions=100000003
- Trace dir: `audit-runs/audit-035-slot-table/`
- Subsystem: front-end UI / save-game / mission-select / HUD (per RAPID-SURVEY-Q4)
## Disasm verification — slot table at r26+108 (5×20=100 bytes)
Confirmed via sylpheed.db query of PC 0x82450720..0x82450918:
- 0x8245088c `addi r30, r26, 108` — slot pointer init
- 0x82450890 `lwz r11, 0(r30)` — load [slot+0]
- 0x82450898 `lwz r9, 4(r30)` — load [slot+4]
- 0x8245090c `addi r30, r30, 20` — advance by 20 bytes
- 0x82450910 `cmpli r25, 0x5` / `blt 0x82450890` — bounded by 5 iters
Audit-034's offset (108) and stride (20) confirmed.
## Canary patch — extension to log r26 + 100-byte dump
Re-applied audit-030 30-LOC `--log_lr_on_pc` patch + extended TrapLogLR to also log r26 and dump 5×20-byte slot table from r3+108 (r3 == r26 after the function's `mr r26, r3` prologue, which has not yet run at PC 0x82450720). Total +49 LOC across 4 files (well under the 80-LOC budget). Build: `ninja -f build-Debug.ninja xenia_canary` succeeded. Patch reverted at session close; canary `git status` clean.
## Captured r26 / r3 / slot table
Both runtimes:
- r3 (= r26 after prologue) = **0x828F3B68** at sub_82450720 entry
- slot table base = r3 + 108 = **0x828F3BD4..0x828F3C37** (100 bytes, 5 slots × 20)
- 22 entries captured in canary (~30s wall); ours dump captured at 50M and 500M instructions (identical)
## Final-state slot tables (5 dwords per slot, big-endian)
| Slot | addr | Canary (last entry) | Ours (-n 500M) |
|------|------|---------------------|----------------|
| 0 | 0x828F3BD4 | `00000000 00000000 00000000 00000000 00000000` | `00000000 00000000 00000000 00000000 00000000` |
| 1 | 0x828F3BE8 | `00000000 00000000 00000000 BC3654C0 00000008` | `00000000 00000000 00000000 4024A240 00000008` |
| 2 | 0x828F3BFC | `00000000 00000000 00000000 BC366080 00000008` | `00000000 00000000 00000000 4024AEE0 00000008` |
| 3 | 0x828F3C10 | `00000002 00000005 00000000 00000000 00000000` | `00000000 00000000 00000000 00000000 00000000` |
| 4 | 0x828F3C24 | `00000000 00000000 00000000 BC365520 00000008` | `00000000 00000000 00000000 4024A300 00000008` |
## Byte-level diff
**Match**: slot-shape identical in 4 of 5 slots (slot 0 zero, slots 1/2/4 each hold pointer+size 8). Pointers diverge by heap region: canary `BC3xxxxx` (physical heap), ours `4024xxxx` (v40 bump heap) — same heap-region divergence noted in audit-027/029. The pointed-to objects in ours are vtable-headed (first dword 0x40111860 / 0x401118A0) — valid v40 objects, same shape as canary's physical objects.
**Divergence — slot 3 only**:
- canary `[+0]=0x00000002, [+4]=0x00000005` (counter pair)
- ours `[+0]=0, [+4]=0`
Slot 3 evolves over time in canary: `(0,0) → (0,1) → (0,3) → (0,4) → (1,4) → (1,5) → (2,5)`. [+0] = monotonic push-count, [+4] = current size. **Not a bytes-missing problem**; the slots ARE managed identically — but the queue's state at any given probe instant differs.
## Writer identification (mem-watch on 0x828F3C10..0x828F3C20 in ours)
1066 writes captured. Writer PCs:
- `0x82450c08, 0x82450c40, 0x82450c4c, 0x82450c3c` — within `sub_82450bc4` (the L5 sub_82450638 inner caller, push/pop on slot 3 counters)
- `0x822f8b20` — counter increment, LR back to `0x822f8a78` / `0x822f8b00`
- `0x82323364` — index update, LR `0x82323344` / `0x823232c8`
- `0x8231eee8` — initialization (one-shot at boot)
Ours's slot 3 [+4] cycles: 0→1→2→3→...→0xB→...→0 (push and pop). 165 occurrences of value 1, 160 of value 2, 158 of value 0xA, 109 of 0xB — much higher peak than canary's 5. **Ours is push-popping items at higher rate**; canary's queue accumulates more slowly.
## Reading
The slot table populates IDENTICALLY in shape across both runtimes. The `(stem, sum)` predicate at PC 0x82450904 (`bne 0x8245092C`) compares sub_82451E20's output against `(slot_addr-12, [slot+0]+[slot+4])`. Because:
- Canary slot 1's `(stem=0x828F3BDC, sum=0xBC3654C8)` matches early when sub_82451E20 returns the right pair → early-exit at iter 1
- Ours slot 1's `(stem=0x828F3BDC, sum=0x4024A248)` cannot match sub_82451E20's output if sub_82451E20's hash/lookup walks via `[sub_8228E498(working_key)+0][32]` and that table is populated with **physical-heap pointers** (canary side) vs **v40 pointers** (our side)
The stem (slot_addr - 12) is identical; the sum is heap-region-dependent. **The lookup table queried by sub_82451E20 + sub_8228E498 contains canary-style physical-heap pointers**, but ours's slot table contains v40 pointers. So the cross-table comparison fails on EVERY iter for ours, until the FALLBACK slot 4 (which seems to be a self-referential default) matches.
This connects directly to **audit-027/029's finding**: our impl's mm_allocate_physical_memory_ex folds into the v40 bump allocator instead of allocating in a separate physical heap. The objects in physical heap on canary live at `BC3xxxxx`; ours at `4024xxxx`. The slot table records the address the producer wrote, but the lookup table sub_82451E20 walks (via sub_8228E498's vptr[32] table) is populated with canary-physical addresses on canary, v40 addresses on ours. The hash/index from those tables is then compared to slot data populated from a different allocator.
**Bug class: ε — heap-region-mismatch propagating through dual-data-structure consistency check.** Canary's physical-heap allocator places these specific objects at predictable addresses that match the lookup table's entries; ours's v40 fold-down places them at different addresses, causing per-element inconsistency.
## Sharp 4-dim cascade prediction
A: implement physical-heap separation in nt_allocate_virtual_memory / mm_allocate_physical_memory_ex (per CPPBUG-AUDIT-001 backlog). The targets at 0xBC3xxxxx range need to be allocated in a separate region.
B: with physical heap separated, sub_8228E498's vptr-table contains 0xBC3xxxxx pointers AND slot-table writers at sub_82450bc4 push 0xBC3xxxxx pointers — same heap region.
C: predicate at 0x82450904 matches at iter 1-2 → early-exit, sub_82450720 returns r3=1.
D: sub_82450638's second call (LR=0x824506cc) frequency normalizes to ~10× per L5 entry (canary's rate) → frame-chain divergence closes; cluster activation MAY clear (`draws > 0` cascade UNKNOWN until B-C observed).
**Risk**: ε might be only ONE of multiple heap-region divergences across the cluster. Audit-027/029 already eliminated v80 + v40 + physical heaps as the dispatch-table source for the renderer plateau, but slot/vtable cross-references may still pin to specific heaps.
## Falsification
Audit-034's hypothesis of "different positions in the 5-slot table" — falsified. The matching slots are at the SAME indices (1, 2, 4 are populated identically in shape). The mismatch is in the VALUE at the slot, not its position.
## Discipline gate
- 1 milestone declared: AUDIT-035. PASS
- 1 outcome captured: ε-class heap-region mismatch at slot data + lookup table. PASS
- 1 sharp next-session prediction: A (implement physical-heap separation) → B → C → D. PASS
- ≤2 hours wall: ~30 min. PASS
- No xenia-rs source mods, no xenia-rs commit. PASS
- Canary patch reverted, git status clean. PASS
## Files
- `audit-runs/audit-035-slot-table/canary-0x82450720.log` — initial trace (r26 logged from caller, table addr offset)
- `audit-runs/audit-035-slot-table/canary-0x82450720-fix.log` — corrected trace using r3+108 (132 lines, 22 entries)
- `audit-runs/audit-035-slot-table/ours-lrtrace.jsonl` — ours's lr-trace (16 entries, r3=0x828F3B68 confirmed)
- `audit-runs/audit-035-slot-table/ours-dump-stdout.log` — ours --dump-addr output (slot table at end-of-run)
- `audit-runs/audit-035-slot-table/ours-memwatch-slot3.log` — 1066 writers to slot 3 (PC + LR + value)
## Master
xenia-rs HEAD `9028021` unchanged. Tests 640. Lockstep instructions=100000003. Canary `git status` clean.
## Recommended AUDIT-036 directions
1. **Land physical-heap separation** (CPPBUG-AUDIT-001 nt_allocate_virtual_memory, mm_allocate_physical_memory_ex). Test against lockstep digest. Probe: re-run AUDIT-035 trace with separated heaps; expect slot 1/2/4 pointers to land at 0xBC3xxxxx, matching canary; predicate to early-exit at iter 1-2; L5→L6 multiplier normalize from 1.14→1.71.
2. **Or, walk further upstream**: identify the producer that POPULATES the lookup table sub_8228E498 reads from. If that producer reads from a DIFFERENT allocator state than the slot-writer (sub_82450bc4), the bug may live there.
3. **Cross-validate**: probe sub_8228E498 (the Tier-1 cluster external) in BOTH runtimes — its r3 (input working_key) and `[r3+0][32]` (returned table value) tell whether the lookup table itself diverges. If ours's table value is `0x4024xxxx` and canary's is `0xBC3xxxxx`, that confirms the heap-region cross-reference hypothesis.

135
migration/claude-memory/project_xenia_rs_audit_036_vptr_deref_2026_05_09.md Normal file
View File

@@ -0,0 +1,135 @@
# KRNBUG-AUDIT-036 — direct hypothesis test of `[[r3+0]+32]` predicate at sub_8228E498
- Date: 2026-05-09
- Mode: READ-ONLY (canary patch landed + reverted; no xenia-rs source change)
- Master: `9028021936e7bddada0c911acc7b61f04fee3b9d` unchanged; tests 640; lockstep instructions=100000003
- Trace dir: `audit-runs/audit-036-vptr-deref/`
- Subsystem: front-end UI / save-game / mission-select / HUD (audit-009 cluster, RAPID-SURVEY-Q4)
- Verdict: **REFUTED-AS-STATED, but a STRONGER divergence found**
## Disasm verification — what `[[r3+0]+32]` actually is
`sub_8228E498` is NOT a vtable[8] dispatcher. Disasm at PC 0x8228E498..0x8228E4CC:
```
8228E498 lwz r9, 0(r3) ; r9 = [r3+0] = header* (NOT vptr)
8228E49C lwz r10, 4(r3) ; r10 = [r3+4] = packed (chunk_idx, sub_idx)
8228E4A0 srwi r11, r10, 2 ; r11 = chunk_idx
8228E4A4 clrlwi r10, r10, 30 ; r10 = sub_idx (low 2 bits)
8228E4A8 lwz r8, 8(r9) ; r8 = [header+8] = chunk_count
8228E4AC..B4 ; chunk_idx = chunk_idx % chunk_count
8228E4B8 lwz r9, 4(r9) ; r9 = [header+4] = segment_table_base
8228E4BC..C0 ; r11 *= 4, r10 *= 4
8228E4C4 lwzx r11, r9, r11 ; r11 = segment_table[chunk_idx]
8228E4C8 add r3, r11, r10 ; r3 = chunk_ptr + sub_offset
8228E4CC blr ; return r3 = element_address
```
This is a **deque/segmented-array iterator dereference** — returns the address of an element. Zero call-xrefs to vtables.
Caller `sub_82451E20` at LR PC `0x82451E78`:
```
82451E70 addi r3, r1, 80 ; r3 = stack-resident iterator (pair of begin/end)
82451E74 bl 0x8228E498 ; r3 = element_ptr
82451E78 lwz r11, 0(r3) ; r11 = [element_ptr+0] <-- THE VALUE OF INTEREST
82451E7C lwz r11, 32(r11) ; r11 = [[element_ptr+0]+32]
82451E80 sub r11, r28, r11 ; r28 = caller's r6 (3rd arg, search-key); compare
82451E84..8C ; cntlzw + extrwi → "is_zero" predicate
82451E90 bne cr6, exit ; exit loop on match
```
So the audited expression `[[r3+0]+32]` is read AFTER sub_8228E498 returns, on its return value (r3 = element_ptr). The predicate is `r28 == [[element_ptr+0]+32]`.
## Canary patch — 49 LOC, reverted at session close
Re-applied audit-030 base patch (30 LOC). Extended `TrapLogLR` in x64_emitter.cc to additionally log: r3, r28, then `[r3+0]` (= "key"), then 64 bytes at the key (16 u32 lanes + ASCII). Total ≈49 LOC across 4 files. Build via `ninja -f build-Debug.ninja xenia_canary`. Reverted via `git checkout -- src/`; canary `git status` clean post-session.
Probed PC `0x82451E78` (the LR return point) for ~30s; sub_82451E20 fires 36 times (108 TRACE-PC- lines = 1 LR + 1 EL + 1 KEY + 1 KEY-ASCII × ~36). Single thread `F8000098`.
## Captured values — direct hypothesis test
### Canary (LR=0x82451E78, ~36 fires)
Element pointers (r3) returned by sub_8228E498:
`0xBC22CA20`, `0xBC22CA24` — physical heap, contiguous. Stride 4 bytes.
`[r3+0]` (= key pointer) — 6 distinct values:
`0xBC65D018, 0xBC65D140, 0xBC65D1C0, 0xBC65D240, 0xBC65D340, 0xBC65D400, 0xBC65D540` — all in physical heap `0xBC65xxxx`.
Key struct layout (16 u32 lanes from one fire, key=`0xBC65D1C0`):
```
F80000B8 00000000 00000000 00000003 00000000 00000000 00000000 00000000
BC65D018 BC65D140 00000000 BC65D034 00000000 00000000 00000001 00000000
^idx0=hdr-handle ^idx8 = [+32] = HYPOTHESIS TARGET
```
ASCII: `'.................................e...e.@.....e.4................'` (only `'e'`=0x65 from 0xBC65 pointers visible — pure pointer-bearing struct, no inline string).
**Canary's `[[r3+0]+32]` = 0xBC65D018 / 0xBC65D2D8 / 0xBC65CFD8 / 0xBC65D118 / 0xBC65D198 / 0xBC65D398 — all phys-heap pointers, range 0xBC65xxxx.**
### Ours (PC=0x8228E498 + dump-addr at returned r3, ~62 fires)
Element pointers (r3) returned by sub_8228E498:
`0x401119B0, 0x401119B4, 0x401119B8, 0x401119BC` — v40 bump heap, stride 4 bytes (same shape as canary).
`[r3+0]` (= key pointer) — values `0x40542300, 0x40542340, 0x40542400, 0x405424C0` (and others) — all in v40 bump heap `0x4054xxxx`.
Key struct layout (64 bytes at 0x40542300, big-endian):
```
+0x00: 67 61 6d 65 3a 5c 68 69 64 64 65 6e 5c 52 65 73 "game:\hidden\Res"
+0x10: 6f 75 72 63 65 33 44 5c 43 6f 6d 6d 6f 6e 2e 78 "ource3D\Common.x"
+0x20: 70 72 00 5c 93 9a 9d cc 69 d8 e4 5c 97 3a 5c 0a "pr.\....i..\.:\."
+0x30: aa b2 16 c3 5e e7 0e 0a 69 d8 e4 5c c2 95 ea d8 ....^...i..\....
```
The "key" record at 0x40542300 is a struct beginning with the **inline filename string** `"game:\hidden\Resource3D\Common.xpr\0"` followed by 8-byte timestamps and other fields.
**Ours's `[[r3+0]+32]` = 0x7072005C** (the four bytes `"pr\0\\"` from mid-string at offset 0x20).
### Side-by-side
| Quantity | Canary | Ours |
|----------|--------|------|
| element_ptr (r3 returned) | `0xBC22CA20+` (physical heap) | `0x401119B0+` (v40 bump heap) |
| `[r3+0]` (key ptr) | `0xBC65D1C0` (phys-heap struct) | `0x40542300` (v40 inline-string struct) |
| `[[r3+0]+32]` ★ | `0xBC65D018` (phys-heap pointer) | `0x7072005C` (mid-string text "pr\0\\") |
| r28 (search key) | `0x7064FB18` (stack ptr) | `0x715978D0` (stack ptr) |
| match? | possible (same address space) | impossible (text never == stack ptr) |
## Verdict — hypothesis REFUTED-AS-STATED, deeper divergence found
**As-stated**: audit-035's hypothesis "ours's `[[r3+0]+32]` is a `0x4024xxxx` pointer; canary's is `0xBC3xxxxx`" is REFUTED. Neither value is a heap-region pointer; canary's is `0xBC65xxxx` (physical heap, but a different sub-range from audit-035's slot pointers `0xBC36xxxx`), and ours's is `0x7072005C` (literal filename text bytes).
**Stronger finding**: the records held by the container differ in *layout*, not just heap region. Canary's record at `[r3+0]` is a 16-dword pointer-bearing struct (handle at +0, sub-pointers at +32/+36/+44). Ours's record at `[r3+0]` is a struct that begins with a 33-byte inline filename string, so offset 32 falls inside the string text. The predicate `r28 == [[r3+0]+32]` therefore COMPARES STACK POINTERS against TEXT BYTES in ours — a comparison that can never succeed regardless of what r28 holds.
This is **bug class η — record-layout divergence (NEW class beyond audit-035's "heap region" axis)**. The container itself (the deque walked by sub_8228E498) is shaped identically in both runtimes — same stride, same iterator semantics. The difference is in the *populator* that filled each record: canary's writes a pointer-table struct; ours writes an inline-string struct.
Audit-035's "heap-region cross-reference hypothesis" — the slot-table predicate fails because the heap regions differ — is **partially confirmed at the surface** (slot pointers DO differ by region: BC vs 4024) but **the actual predicate failure mechanism is different**. The match fails not because pointers can't cross-reference between heap regions (they can — both addresses are valid in their respective spaces) but because **the structs at those addresses encode different fields at offset 32**.
## Recommendation — DO NOT proceed with physical-heap separation fix
Audit-037 should NOT be the physical-heap split (CPPBUG-AUDIT-001). That fix was motivated by audit-035's heap-region narrative. Today's data shows the actual divergence is in the *content/layout* of records, so even after splitting heaps, ours's records would still hold inline strings while canary's hold pointer structs — predicate would still fail.
**Recommended audit-037**: identify the record populator(s) that build the container at element-pointers `0x401119B0+` (ours) vs `0xBC22CA20+` (canary). The populator writes the struct at `[r3+0]`. Likely path: mem-watch on a representative ours record (e.g. `0x40542300+0x20`) to find the writer PC and LR, then disasm the writer's caller chain and compare to canary's equivalent record-construction site. The two populators should diverge at a static-init or resource-loader function — that divergence is the audit-037 bug, and likely a much smaller fix than physical-heap separation.
Sharp 4-dim cascade prediction (post-fix):
- A: ours's `[0x40542300+0x20]` = a phys-style pointer (matches canary's record-shape)
- B: predicate `r28 == [[r3+0]+32]` matches at least once during boot
- C: sub_82451E20 inner loop exits via `bne cr6, 0x82451EB4` (taken), not via `cmplwi r11, 0x0 / beq` end-of-iteration
- D: cluster `0x82285000-0x82294000` external-entry probes (audit-033) show new fires — start of full activation
## Tooling status
- `--pc-probe` / `--branch-probe` work at function-entry PCs but NOT at mid-flow `lwz`/`addi` etc — those JIT instructions don't get instrumented. Used `--dump-addr` post-hoc to read returned-r3 records (stable v40-heap, not transient stack).
- Canary patch (49 LOC) successfully extended TrapLogLR to read GUEST MEMORY via `memory->TranslateVirtual<xe::be<uint32_t>*>(...)`. Pattern reusable for future canary-side struct probes.
- All probe scripts read-only; no source changes; no commits. xenia-rs HEAD `9028021` unchanged at session close.
## Files
- `audit-runs/audit-036-vptr-deref/canary.log` — initial 30s canary at PC=0x8228E498 (segment-array deque dump)
- `audit-runs/audit-036-vptr-deref/canary-callsite.log` — extended canary at PC=0x82451E78 (key + 64-byte struct dump)
- `audit-runs/audit-036-vptr-deref/ours.log` / `ours-dump.log` — pc-probe + dump-addr at stack r3
- `audit-runs/audit-036-vptr-deref/ours-exit.log` — branch-probe at 0x82451E78 (returned r3 = 0x401119B0+)
- `audit-runs/audit-036-vptr-deref/ours-final.log` — dump-addr at element pointers + their key targets
Discipline gate (5/5):
1. Hypothesis explicitly tested with sharp pre-prediction: PASS
2. Canary patch reverted at session close, `git status` clean: PASS
3. xenia-rs source unmodified, no commit: PASS
4. Single-step (validation only, no fix attempt): PASS
5. Trace files saved per audit dir convention: PASS

94
migration/claude-memory/project_xenia_rs_audit_039_track_1_verify_2026_05_09.md Normal file
View File

@@ -0,0 +1,94 @@
# AUDIT-039 Track 1: Cache-Fix Record-Layout Verification (2026-05-09)
**Status**: READ-ONLY — pure diagnostic verification of cascade dimension A from audit-038. No source mods, no commit.
**Master HEAD**: `d8766c6` (post audit-038 cache fix). Tests 645. Lockstep instructions=100000004 deterministic ×3.
**Predecessor**: audit-037 (record populator, pre-fix) + audit-038 (cache fix).
**Sister session**: Track 2 — extended-horizon canary trace for cluster activation (parallel, untouched).
## Question
Did audit-038's cache fix flip the record layout at v40 0x40542xxx from **inline-string** (pre-fix shape, captured audit-037) to **canary-shape pointer-bearing** (handle@+0=0xF80000B8, sub-pointers@+32/+36/+44)?
## Method
1. Probe `sub_8228E498` (deque iterator deref) at -n 500M to capture live record-base addresses. **Result: 0 fires** — silenced by audit-038's cache fix (sub_8228E498 is downstream of the cache-miss path that is now fully short-circuited).
2. Fallback: dump audit-037 record bases directly via `--dump-addr=0x40542300,0x40542340,0x40542400,0x405424C0`. Plus extended-range dump 0x40542100,0x40542200,0x40542500,0x40542600,0x40542700,0x40542800.
3. Cross-reference canary record shape from audit-037's canary probe of `0x82450b68` (records on canary heap at `BC65xxxx`).
## Observed Record Bases (post-fix, master d8766c6)
All 4 audit-037 record bases are still allocated and contain identical or near-identical data to pre-fix:
### 0x40542300 — IDENTICAL to pre-fix
```
+0x00: 67 61 6d 65 3a 5c 68 69 64 64 65 6e 5c 52 65 73 | "game:\hidden\Res
+0x10: 6f 75 72 63 65 33 44 5c 43 6f 6d 6d 6f 6e 2e 78 | ource3D\Common.x
+0x20: 70 72 00 5c 93 9a 9d cc 69 d8 e4 5c 97 3a 5c 0a | pr.\..i...\.:\.
+0x30: aa b2 16 c3 5e e7 0e 0a 69 d8 e4 5c c2 95 ea d8 |
+0x40: 40 54 28 80 00 00 00 00 00 00 00 02 00 00 00 03 |
...
```
**+0x20 dword = 0x7072005C ("pr\0\\")**, IDENTICAL to audit-037 pre-fix.
### 0x40542340 — descriptor-shape (header)
```
+0x00: 40 54 28 80 ... | be32=40542880 (ptr to next record)
+0x40: 40 54 1f 40 40 54 1f 40 64 64 65 6e 40 54 23 00 | "...dden@T#."
+0x50: 6f 75 72 63 65 33 44 5c 43 6f 6d 6d 00 00 00 22 | "ource3D\Comm..."
```
### 0x40542400 — descriptor-shape
```
+0x00: 40 54 24 80 ... | be32=40542480 (ptr)
+0x40: 40 54 26 00 40 54 1e c0 40 54 25 40 5f 54 49 54 | "@T&.@T..@T%@_TIT"
```
### 0x405424c0 — pointer-bearing PARTIAL
```
+0x00: 40 54 25 80 ... | be32=40542580 (ptr)
+0x20: 40 54 1e d8 00 00 00 00 00 00 00 00 40 54 1e f4 | be32=40541ed8 ... 40541ef4
+0x40: 40 54 23 40 3a 5c 68 69 64 64 65 6e 5c 52 65 73 | "@T#@:\hidden\Res
+0x50: 6f 75 72 63 65 33 44 5c 70 74 63 5f 70 61 63 6b | "ource3D\ptc_pack
```
**+0x20 dword = 0x40541ED8 (pointer)** — descriptor-shape; **+0x44 onward holds inline path string** "game:\hidden\Resource3D\ptc_pack.xpr".
## Canary Comparison (audit-037 ground truth)
Canary populates filenames via `RtlInitAnsiString(BC365xxx,"game:\\hidden\\Resource3D\\Common.xpr")` at `0xBC365xxx` separately from the per-file struct at `0xBC65xxxx` — the struct holds **pointers** (handle@+0=0xF80000B8 + sub-pointers BC65xxxx/BC36xxxx). Strings live on a different heap from records.
Our impl: filenames are **inlined into the record itself** at the record base or at +0x40. No separate filename heap is allocated; the populator path that splits filename→pointer doesn't run.
## Verdict — Cascade Dimension A
**FAIL.** Cache fix (audit-038) did NOT flip record layout to canary-shape.
- 0x40542300: inline-string layout unchanged. +0x20 = 0x7072005C (text bytes "pr\0\\") — IDENTICAL to audit-037 pre-fix.
- 0x405424c0: descriptor-shape with pointers at +0x20, but **filename still inlined at +0x44** rather than externalized to a separate `RtlInitAnsiString`-style heap pointer.
- No record begins with `0xF80000B8` handle. No record contains BC65xxxx-equivalent sub-pointers. The populator that should externalize filenames into ANSI-string heap before the pointer-bearing record stage is NOT running.
Audit-038's fix is correct hygiene (cache:/* paths persist via `/tmp/xenia-rs-cache-<pid>-<seq>/`); it silenced sub_82459D18/sub_8245D230/0x82450904 (cache-miss/resize path). But the **record-population transformation step** (filename string → ANSI-heap → pointer-bearing struct) is a DIFFERENT mechanism, upstream or sibling to the cache machinery, that audit-038 didn't touch.
## Lockstep Determinism
Probe-element run: `instructions=500000019, imports=5629636, swaps=2, VdSwap=2`. Stable.
## Recommended Next
Cache fix is **necessary but not sufficient**. The hidden Track is:
- **Option A** — find the ANSI-string populator: trace `RtlInitAnsiString` callers in our impl vs canary; specifically the path that takes a `game:\hidden\…` literal and writes it to a fresh heap allocation before the per-file record sees it. If this path doesn't fire in our impl, that's the missing transformation.
- **Option B** — mem-watch the +0x20 dword on a specific record (e.g. 0x40542320) to capture WHO writes the inline-string bytes. The writer's PC + LR identifies the populator function; cross-check whether canary's equivalent function instead writes a pointer.
- **Option C** — let sister Track 2's extended-horizon canary trace land first; if cluster L1 activates in canary at e.g. T+30s, rule out timing/horizon as a confound before declaring transformation-step missing.
- **Option D** — KRNBUG entry: audit our `RtlInitAnsiString` (and adjacent string-init paths) for handling of `cache:/*` vs `game:/*` vs `dat:/*` prefixes; if the populator branches on prefix and we mis-handle one, that's the bug.
Sister Track 2's findings are now load-bearing: if cluster L1 fires in canary at extended horizon, then transformation-step is the gate; if it doesn't fire there either, we need a higher-up activation trigger.
## Trace
`audit-runs/audit-039-track-1-verify/`:
- `probe-element.{out,log}` — pc-probe sub_8228E498 (0 fires) + 4-record dump
- `dump-extended.{out,log}` — extended dump 0x40542100..0x40542800
## Reading-Error Ledger
No new errors. Audit-037's record-base attribution (0x40542300 etc) holds post-fix; audit-038's cache-fix scope is correctly characterized as cache-only (not record-layout).

98
migration/claude-memory/project_xenia_rs_audit_039_track_2_extended_canary_2026_05_09.md Normal file
View File

@@ -0,0 +1,98 @@
# AUDIT-039 Track 2: Extended-Horizon Canary Trace for Cluster Activation (2026-05-09)
**Status**: READ-ONLY — canary instrumentation only (patch reverted at session close). NO xenia-rs source mods, NO commit.
**Canary HEAD**: `6de80dffe` (clean baseline; patch applied + reverted in-session).
**xenia-rs HEAD (untouched)**: `d8766c6` (post audit-038 cache fix). Tests 645.
**Sister session**: Track 1 — cache-fix record-layout verification (parallel, untouched on xenia-rs side).
## Question
At extended horizon (10–15 min, 2–3× longer than audit-034 Phase B's 5 min), does Linux Debug canary EVER reach the audit-009 cluster's Tier-2 callers (`sub_82172524`, `sub_82175810`, `sub_8217EB78`) — and through them the cluster's L1 entries?
If YES → capture LR (caller PC) → name the activation gate.
If NO → cluster activation is past Linux Debug's reach in 15 min → strategic pivot mandatory.
## Method
1. Re-applied audit-030 `--log_lr_on_pc` canary patch (30 LOC across 4 files).
2. Build via `ninja -f build-Debug.ninja xenia_canary` (success, 13 objects).
3. Probed 3 Tier-2 PCs serially with 15-min wallclock each (single PC at a time per audit-031 finding):
- `0x82172524` — actual run 22 min (timeout(1) didn't enforce the 900s SIGTERM cleanly until force-kill)
- `0x82175810` — 15 min wallclock
- `0x8217EB78` — 15 min wallclock
4. Trace marker `TRACE-PC-LR pc=...lr=...r3=...r4=...r5=...r6=...r31=...` per fire.
5. Compressed plan per task brief: skip Tier-1 (3 PCs) + L1 (6 PCs) when Tier-2 = 0× (consequences of Tier-2 firing).
## Result Table
| Tier | PC | Horizon (wall) | Hits | LR captured | Notes |
|------|-------------|----------------|------|-------------|--------------------------------------------------|
| T2-A | 0x82172524 | 22 min | **0** | — | Steady-state idle: 240k KeReleaseSemaphore / 75k texture-load loop |
| T2-B | 0x82175810 | 15 min | **0** | — | Steady-state idle (same kernel-call mix) |
| T2-C | 0x8217EB78 | 15 min | **0** | — | Steady-state idle (same kernel-call mix) |
Total wallclock: ~52 min canary CPU. All three external Tier-2 callers of the cluster STAYED 0× across extended horizons.
## Steady-State Engine Mix (representative T2-A 22 min)
```
240438 KeReleaseSemaphore(828A3230, 1, 1, 0) ← audio sema repeat
74635 VdRetrainEDRAM, VdGetSystemCommandBuffer ← renderer idle pump
74635 XamInputGetCapabilities(0..3) ← input poll
432 Kernel object Removed; 396 Added; 381 NtStatusToDosError
```
Identical mix in T2-B, T2-C. Engine reaches the same plateau as 5-min Phase B but progresses no further across 3× the wallclock. RECONCILE-A's "Linux reaches frame 42/186 vs Lutris Windows 72/186 in 10× more time" framing holds: the engine is alive at the kernel-call level but not advancing through the front-end-UI / save-game state machine.
## Verdict — OUTCOME (ii)
**Cluster activation is past Linux Debug's reach in 15 min.** Per task brief Step 3 outcome (ii):
> Tier 2 stays 0× even at 15 min: cluster activation is past Linux Debug's reach in 15 min. The gate may be tied to intro-video duration / state-transition that Linux can't reach (per RECONCILE-B host-presenter caveat).
Confirms and extends audit-034 Phase B (5 min, 0× Tier-2/3) and VERIFY-A (35 sec, 0/12 cluster L1). The static-reachability claim from audit-009 stays sound; the runtime gate is genuinely upstream of Tier-2 calls in the front-end-UI subsystem.
## Strategic Implication
The **shared Linux-host-presenter caveat (RECONCILE-B)** dominates: Vulkan/XCB on Linux fails to display intro video; user confirmed Weston also shows black; the front-end-UI state machine never advances past the post-intro state-transition that Tier-2 callers gate on. Three independent canary horizons (35 sec / 5 min / 15 min) all stop in the same idle loop.
Methodology consequence: **15-min Linux Debug canary cannot witness the cluster activation event on this host.** Continued probing at higher horizons on Linux is unlikely to yield. Two pivots open:
- **Pivot A — Lutris Windows canary instrumentation.** The user's Lutris Windows build of canary reaches further (frame 72/186 in observed traces). Re-port the `--log_lr_on_pc` patch to a Windows build and probe Tier-2 there. Higher cost (Windows toolchain, Lutris config, longer iteration), but could finally witness Tier-2 fires and LR-name the trigger.
- **Pivot B — Static-only path forward.** Drop runtime probing on this side; lean on M5.5 (alias-aware vtable dispatch resolution per analysis-overhaul SCHEMA.md) to statically name the gate function in xenia-rs's IDA database, then probe THAT function in our impl + canary-Linux at 5-min horizon to see if it fires there at all.
**Recommendation**: Pivot B first (low-cost, exhausts static analysis avenue per audit-029 verdict); Pivot A as fallback if M5.5 doesn't reach a probeable witness.
## Sister-Session Coordination
Track 1's verdict on cascade dimension A: **FAIL** — audit-038 cache fix did NOT flip record layout to canary-shape. Track 1 recommended waiting for Track 2 before declaring transformation-step missing (Option C) to rule out horizon-as-confound. Track 2 now rules that out: 15-min horizon does not move the needle. Combined hand-off: **transformation-step (RtlInitAnsiString-driven filename externalization) IS missing AND cluster activation IS past Linux Debug's reach.** These are independent gates; Track 1's Option A (trace `RtlInitAnsiString` callers on the `game:/dat:/cache:` prefix family) becomes the next concrete xenia-rs-side action regardless of cluster activation horizon.
## Falsifications
- Audit-034 Phase B's "5 min may be too short" caveat is now closed: 15 min doesn't reach Tier-2 either.
- Hypothesis "extended horizon would witness cluster activation" — falsified for Linux Debug at 15 min.
## Trace
`audit-runs/audit-039-track-2-extended-canary/`:
- `canary-0x82172524.{log,err}` — 77 MB log, 0 fires, 22-min wall (force-killed)
- `canary-0x82175810.{log,err}` — 52 MB log, 0 fires, 15-min wall
- `canary-0x8217EB78.{log,err}` — 55 MB log, 0 fires, 15-min wall (force-killed at +3s post-timeout)
## Cleanup
- Canary patch reverted: `git checkout -- src/`; `git status` clean; HEAD `6de80dffe` unchanged.
- xenia-rs source unmodified, no commit, no push.
- Sister Track 1's territory (xenia-rs runtime probe) untouched.
## Discipline Gate (5/5 PASS)
1. Hypothesis explicitly tested with sharp pre-prediction (Tier-2 fires → LR-names gate; 0 fires → outcome ii).
2. Canary patch applied + reverted at session close (clean baseline confirmed).
3. xenia-rs source unmodified, no commit.
4. Single-step (verification only, no fix attempt).
5. Trace files saved per audit dir convention.
## Reading-Error Ledger
No new errors. Reaffirms (does not contradict) the cluster's "front-end UI / save-game / mission-select" subsystem identity per RAPID-SURVEY-Q4 (NOT renderer plateau).

131
migration/claude-memory/project_xenia_rs_audit_040_record_ctor_inputs_2026_05_09.md Normal file
View File

@@ -0,0 +1,131 @@
# KRNBUG-AUDIT-040 — record ctor input divergence (sub_8244FC90)
**Date:** 2026-05-09 (session 1 of 10-session autonomous budget)
**Status:** READ-ONLY. Canary patch applied + reverted. Master HEAD `d8766c6` unchanged. Tests 645.
**Lockstep:** instructions=100000004, swaps=2, draws=0 (plateau).
## Goal
Identify the divergent INPUT to `sub_8244FC90` (record ctor) between canary and ours. Per audit-037 the ctor fires identically in both impls but produces different layouts (canary = pointer-bearing, ours = inline-string).
## Method
Re-applied audit-030 `--log_lr_on_pc` canary patch and EXTENDED `TrapLogLR` to log r3..r10 + r28..r31 + LR + a 32-byte hex dump from `*r4` and `*r5` (sub_8244FC90 is `_init(this=r3, src=r4, struct=r5, arg=r6, arg=r7)` per disasm). +56 LOC across 4 files (under 80 LOC cap). Build via `ninja -f build-Debug.ninja xenia_canary`. Saved patch reference at `audit-runs/audit-040-record-ctor-inputs/canary-patch.diff`. Reverted at session close (`git status` clean).
Captured 30 s canary trace at `--log_lr_on_pc=0x8244FC90` (33 fires). Captured ours via `--lr-trace=0x8244FC90` (8 fires) + `--dump-addr` against the recurring r4/r5 values.
## Calling convention (sub_8244FC90, from sylpheed.db disasm 0x8244FC90..0x8244FD30)
- **r3** = dest record (allocated by caller via `operator new` at `sub_824503A0+0x418`)
- **r4** = source struct ptr (28 bytes; saved as r29; loop at +0xFD1C..+0xFD2C copies 7 dwords from `*r4` to `r31+60`)
- **r5** = secondary "this" ptr (stored at `r31+36`, vtable bearing in canary)
- **r6** = scalar (stored at `r31+48`)
- **r7** = scalar (stored at `r31+52`)
## Concrete register snapshots (one representative fire each)
| reg | canary (fire 2) | ours (fire 2) |
|-----|-----------------|---------------|
| r3 | `BC65D440` | `405420C0` |
| **r4** | **`BC79C9EC`** | **`406819EC`** |
| r5 | `BC65D2C0` | `40542100` |
| r6 | `BC79C9C4` | `406819C4` |
| r7 | `0000000C` | `40542100`-region |
| LR | `82450440` | `82450440` |
Both impls call from the **same site** (LR = `0x82450440` = `sub_824503A0+0xA0`, the `bl 0x8244FC90` instruction).
## The divergence — content of `*r4` (the 28-byte source struct memcpy'd into the record)
| word | canary `0xBC79C9EC` | ours `0x406819EC` (≈ same role at `0x40681A4C`) | classification |
|------|---------------------|-----------|----------------|
| +0 | **`F80000DC`** | **`00001454`** | **DIFFERENT** — kernel handle vs handle |
| +4 | `00000000` | `00000000` | same |
| +8 | `00000000` | `00000002` | DIFFERENT |
| +12 | `00000003` | `00000003` | same |
| +16 | `00000000` | `0000000C` | DIFFERENT |
| +20 | `0000000C` | `0000000C` | same |
| +24 | `00000000` | `00000000` | same |
The first dword (the slot at `[r31+44]` of `sub_822DFBC8`'s "this") is the load-bearing divergence: it is later read at `sub_822DFBC8+0x5C` (`lwz r3, 0(r30)`) and waited on via `bl 0x824AA330` (= `WaitForSingleObject(handle, -1)`).
## Upstream caller — where the divergent dword originates
Backtrace from sub_8244FC90 entry:
```
frame 0 sub_8244FC90 (r3=dest, r4=*src-struct)
frame 1 sub_824503A0+0xA0 bl 0x8244FC90 (LR=0x82450440)
frame 2 sub_824528A8+0x90 bl 0x824503A0 — vtable forwarder, r9=src-struct
frame 3 sub_822DFBC8+0x40 bcctrl 20,lt — vtable[7] of [r31+40], r8=r31+44
frame 4 sub_822DFCC4 (callers x4 — sub_822DFCC4/E20/ECC, sub_822E0334)
```
In **sub_822DFC74** (the +0x822DFCC4 caller frame), the slot at `r31+44` is populated as:
```
0x822DFC8C-90 r3=r4=r5=r6=0; bl 0x824A9F18 ; create event, returns handle in r3
0x822DFC94 or r4, r3, r3 ; r4 = handle
0x822DFC98-9C r3 = r1+80; bl 0x821820B0 ; stw r4, 0(r3) at r1+80
0x822DFCA0 lwz r11, 80(r1) ; r11 = handle
0x822DFCB8 stw r11, 44(r31) ; *** [this+44] = handle ***
0x822DFCC4 bl sub_822DFBC8 ; dispatch (memcpys this+44 into record)
```
`sub_824A9F18` is a **wrapper around `NtCreateEvent`** (xboxkrnl.exe ordinal 209, at thunk `0x8284DF1C`). It calls `bl 0x824AC268` which itself uses `RtlInitAnsiString` (ordinal 300) for the optional name.
So the divergent dword is **the OUT handle returned by `NtCreateEvent`**:
- canary: `NtCreateEvent` → `0xF80000DC` (kernel-region pseudo-handle, canary's `XObject` namespace)
- ours: `NtCreateEvent` → `0x00001454` (small-int handle ID, our `KernelState::handle_table` namespace)
## Bug-class refinement
This is **NOT a logic bug in our code path**. Both impls call `NtCreateEvent` 395 times during boot; both succeed. The DIVERGENCE is **handle-namespace cosmetics**: canary returns `0xF8000xxx`, ours returns `0x10xx-0x14xx`. Both are valid handle values within their own kernel.
**However:** the divergent dword IS the load-bearing first-word of the source struct that sub_8244FC90 memcpys into the record. The downstream code interprets `[record+0x3C]` as a handle and does `WaitForSingleObject(handle, INFINITE)` — which works in both runtimes. This handle-namespace divergence is therefore NOT a stuck state in the record-ctor flow itself.
The audit-037 framing of "canary records hold pointer-bearing structs while ours holds inline-string structs" needs a careful re-read:
- The 28 bytes copied at sub_8244FC90 (record `+0x3C..+0x57`) ARE different in handle slot, but only by namespace.
- The "filename text starting at +0" the audit-037 saw must be at a DIFFERENT offset of the dest record (e.g. `+0x40..` of our `0x40542100` dump shows `40541F80 40542000 745c4750` then ASCII `LE.pak\0eng\p`) — that's the SECOND dword block written by sub_824503A0 AFTER sub_8244FC90 returns, NOT the source struct.
**Provisional class:** δ-namespace (handle representation divergence; lossy round-trip when guest treats handle as semantically meaningful in a struct field). Sister of the audit-024A "F8 vs heap pointer" class.
## Falsifications
- The 11-fire claim from audit-037 is too low — 30 s canary window yields 33 fires, suggesting earlier session terminated too quickly (≤ 10 s effective trace).
- The "record holds inline-string struct" framing is partially incorrect: the inline string lives in the dest at offset `+0x40+`, written by sub_824503A0 OR a subsequent write — not by sub_8244FC90's memcpy. Track-1's "filename text starting at +0" finding is approximate; needs re-verification against record offset boundaries.
## Recommended audit-041
**Two parallel options:**
1. **DOWNSTREAM-USE PROBE (preferred)** — instrument the record AFTER sub_8244FC90 returns. Where does the record's `+0x3C` (handle slot) get READ in canary vs ours? If both runtimes correctly route the handle through `WaitForSingleObject` then the namespace divergence is benign and the actual blocker is elsewhere. Probe `sub_822DFC34` (`bl 0x824AA330`) entry in BOTH runtimes; capture r3 = handle being waited on; verify wait completes (signal source). Targeted PCs: `0x822DFC34` (waitsite), `0x824AA330` (KeWaitForSingleObject thunk).
2. **AUDIT-037 RE-VERIFICATION** — re-read audit-037's "record at +0x40 has filename text vs canary has pointers" claim against the new ground truth. Specifically dump 128 bytes from canary's `r3=BC65D440` and ours's `r3=0x405420C0` AT THE EXIT of sub_8244FC90 (not at session-end which is far later). If the filename-text-at-+0x40 bytes are written by sub_824503A0+0x478 (`bl 0x822F8A70` / `bl 0x82150030`) then those callees are the actual filename-vs-pointer divergence and are the real audit-041 target, not sub_8244FC90 itself.
**Stop conditions for audit-041:** if the downstream probe shows canary's wait at `0x822DFC34` ALSO never completes (matching ours), the handle-namespace finding is benign and the gate is upstream of `WaitForSingleObject`; pivot to RDX-search-criteria producer. If canary's wait completes but ours doesn't, it's a **signaler-missing** bug; trace which kernel call signals canary's `0xF80000DC` event handle.
## Trace artifacts
- `audit-runs/audit-040-record-ctor-inputs/canary-0x8244FC90.log` (33 canary fires + dumps)
- `audit-runs/audit-040-record-ctor-inputs/ours-lrtrace.jsonl` (8 fires r3-r6+LR JSONL)
- `audit-runs/audit-040-record-ctor-inputs/ours-dump.log` (10 dump-addr snapshots)
- `audit-runs/audit-040-record-ctor-inputs/canary-patch.diff` (notes/reference, code reverted)
## Ledger update
This audit ADDS one entry to the running 11-error ledger:
- **Subsystem-mislabel adjacent:** "audit-037 r4 source struct = inline filename" → corrected to "r4 source struct = NtCreateEvent handle slot at this+44 of sub_822DFBC8's class instance". The filename text lives in a DIFFERENT region of the dest record, written by a sibling callee (`sub_822F8A70` / `sub_82150030` family).
## Discipline gate
5/5 PASS:
- Read-only on xenia-rs source: PASS
- Canary patch reverted (`git status` clean): PASS
- ≤80 LOC patch: PASS (56 LOC)
- No fix this session: PASS
- Sharp prediction provided for audit-041: PASS
## Master HEAD
xenia-rs `d8766c6` unchanged (645 tests). xenia-canary `6de80dffe` clean post-revert.

133
migration/claude-memory/project_xenia_rs_audit_041_wait_site_2026_05_09.md Normal file
View File

@@ -0,0 +1,133 @@
# KRNBUG-AUDIT-041 — wait-site signaler determination (READ-ONLY, 2026-05-09)
**Master HEAD**: `d8766c6` unchanged.
**Canary HEAD**: `6de80dffe` unchanged.
**Tests**: 645. **Lockstep**: instructions=100000004 unchanged.
**Trace dir**: `audit-runs/audit-041-wait-site/`.
## Goal
Determine whether the handle-namespace divergence identified in AUDIT-040
(canary `0xF80000DC` family vs ours `0x00001454` family for event handles
created at sub_822DFC74 → NtCreateEvent ord 209) is **benign** or
**load-bearing** — i.e., does ours actually stall at the wait while
canary completes?
## Method
- Re-applied audit-030 `--log_lr_on_pc` canary patch (30 LOC, 4 files);
rebuilt Linux Debug; reverted at session close (canary clean).
- Identified wait site: PC `0x822DFC34` `bl 0x824AA330`
(KeWaitForSingleObject wrapper, alertable=0, timeout INFINITE).
- Containing function: **sub_822DFBC8** (range 0x822DFBC8..0x822DFC68);
caller LR `0x822DFC0C` (single caller, sub_822DFBC8 itself).
- Wait loop: `0x822DFC30 addi r4,r0,-1` (INFINITE) → `0x822DFC34 bl wait`
→ `0x822DFC38 cmpli cr6,0,r3,0x102` (STATUS_TIMEOUT) → branch to
`0x822DFC18` retry on timeout OR on `[r31+52]==3`.
- Captured 30s canary traces at PC 0x822DFC34 (bl) + 0x822DFC38 (post-bl).
- Captured our impl via `--lr-trace=0x822DFC30,0x822DFC38 -n 500M`
(probing `bl` itself returned 0 fires in our HIR — `bl` is elided as
a control-flow terminator; pre-bl `addi` at 0x822DFC30 is the fair
comparison).
## Findings
### Wait completion ratio
| Runtime | bl/pre-bl fires | post-bl fires | completes? |
|---------|-----------------|---------------|------------|
| canary | 9 | 9 | 9/9 = 100% |
| ours | 7 (pre-bl) | 6 | **6/7 = 85%** |
The 7th wait in ours stalls. Sample handles:
- canary r3: `0xF80000CC`, `0xF80000C0` (kHostHandleBase namespace).
- ours r3: `0x000012C0`, `0x000012FC`, **`0x00001454`** (audit-040 family).
- The stalled 7th wait is on handle `0x00001454`, cycle 48,849. All 6
earlier waits (handles 0x12C0/0x12FC) returned r3=0 (STATUS_SUCCESS).
**Outcome (i) confirmed**: handle-namespace divergence is
**load-bearing**, manifesting as a stalled wait in ours.
### Signaler identification
Probed canary's KeSetEvent thunk (0x8284DDDC) and NtSetEvent thunk
(0x8284DF5C) over 30s. Filter for r3 ∈ {F80000CC, F80000C0}:
- KeSetEvent: 20,588 fires globally, **0** on F80000CC/C0 (KeSetEvent
takes a KEVENT*, not a handle).
- **NtSetEvent: 9,245 fires globally, 2 on F80000CC/C0**:
```
pc=8284DF5C lr=824AA304 r3=F80000C0 r4=00000000 r5=F80000C0 r6=03A72328 r31=BC65CF98
pc=8284DF5C lr=824AA304 r3=F80000CC r4=00000000 r5=F80000CC r6=03A72328 r31=BC65D058
```
**Signaler = NtSetEvent** (xboxkrnl ord 246), thunk PC 0x8284DF5C.
LR=0x824AA304 → wrapper sub_824AA2F0 (single-arg passthrough at
0x824AA300). sub_824AA2F0 has **89 callers** in the static graph; the
actual signaler caller chain is the next investigation step.
### Cross-check: ours fires NtSetEvent on 0x1454?
Probed our impl's NtSetEvent thunk at 0x8284DF5C: 3,334 total fires.
- `r3=0x000012C0` × 1 (cycle 514,138)
- `r3=0x000012FC` × 3
- `r3=0x00001454` × **1** (cycle 3,519,453)
**The signaler IS firing on 0x1454 in ours.** But the wait at cycle
48,849 (much earlier) never returns. So this is NOT signaler-missing in
the trivial sense — the signaler call exists. The signal arrives but
the waiter isn't woken.
## Bug class refinement (provisional)
This is **δ-namespace AND δ-wakeup**, not pure signaler-missing:
- The handle namespace divergence (audit-040) means our `0x1454` is
*some* event in our table, but the NtSetEvent on 0x1454 may resolve
to a *different KEVENT object* than the one our wait registered for —
if our handle table aliases handle slots between Nt-create epochs.
- Alternatively: the signal hits the right object, but our `KeWaitForSingleObject`
/ `KeSetEvent` plumbing has a missed-wake (signal-before-wait race or
event reset path).
- Three sites where pre-bl fires but no post-bl: cycle 48,849 with handle
0x1454. The signal at cycle 3.5M is AFTER the wait registered, so
signal-before-wait race is ruled out.
## Discipline gate (5/5 PASS)
1. Hypothesis explicitly tested (wait-completion-ratio canary vs ours).
2. Canary patch applied (30 LOC) + reverted at session close.
3. xenia-rs source unmodified, no commit.
4. Single-step (data-gathering only, no fix attempt).
5. Trace files saved: `canary-bl-0x822DFC34.log` (4.5 MB),
`canary-postbl-0x822DFC38.log`, `canary-keset-0x8284DDDC.log` (22 MB),
`canary-ntset-0x8284DF5C.log` (11 MB), `ours-pre-bl.jsonl`,
`ours-lr.jsonl`, `ours-ntset.jsonl`.
## Recommended audit-042 (autonomous)
**Priority**: pivot to audit-042 to identify which of NtSetEvent's 89
callers signals our hung 0x1454, AND verify whether the handle binds
to the same KEVENT pointer in both runtimes.
Two-track:
1. **Caller chain**: probe sub_824AA2F0 (NtSetEvent wrapper) entry; on
each fire log r3 + LR + r31. Filter for r3=0x1454 (ours) /
r3=0xF80000CC family (canary). The caller LR + r31 names the
creator-side state machine.
2. **Handle resolution**: in our impl, dump handle table state for slot
0x1454 at cycles 48,849 (wait) and 3,519,453 (signal). Verify that
both lookups return the same `Arc<EventObject>`. If not — handle
table aliases between epochs (creator in audit-040 made a NEW
0x1454 between wait and signal because NtClose recycled the slot).
If handle aliasing confirmed → bug class collapses to handle-recycling
in our slab allocator (`xenia_kernel::handle_table`) — fix is in our
impl, not in the kernel exports.
If handle resolution stable → bug is in our `KeSetEvent` /
wait-queue machinery (signal lands but waiter list pointer is wrong).
Both fixes are small (≤60 LOC) and both fit the discipline budget.

172
migration/claude-memory/project_xenia_rs_audit_042_handle_lifecycle_2026_05_09.md Normal file
View File

@@ -0,0 +1,172 @@
# KRNBUG-AUDIT-042 — handle 0x1454 lifecycle disambiguation (READ-ONLY, 2026-05-09)
**Master HEAD**: `d8766c6` unchanged.
**Canary HEAD**: `6de80dffe` unchanged (patch reverted at session close).
**Tests**: 645. **Lockstep**: instructions=100000004 unchanged.
**Trace dir**: `audit-runs/audit-042-handle-lifecycle/`.
## Goal
Disambiguate audit-041's stall hypothesis for handle `0x1454`:
- **(A)** handle-recycling — slot 0x1454 reused between create-epochs;
signal hits new instance, waiter is on old.
- **(B)** wakeup-plumbing — same KEVENT object, signal lands but
waiter list pointer / wake-eligibility check is wrong.
## Method
- Ours: `cargo run --release -p xenia-app -- exec sylpheed.iso
--halt-on-deadlock --probe-db=sylpheed.db
--trace-handles-focus=0x1454 -n 500_000_000`
(existing `xenia_kernel::audit` infrastructure; no source mods).
Two reruns identical.
- Canary: re-applied `audit-030-lr-trace/canary-patch.diff` (30 LOC,
4 files); rebuilt Linux Debug; ran with `--log_lr_on_pc=0x8284DF1C`
(NtCreateEvent thunk, ord 209). Reverted at session close.
- Cross-ref: re-grepped audit-041's existing `canary-bl-0x822DFC34.log`
for `Added handle:` / `Removed handle:` lifecycle markers.
## Findings
### (1) Allocator architecture — ours
`KernelState::alloc_handle` (state.rs:588-593):
```rust
pub fn alloc_handle(&mut self) -> u32 {
self.next_handle.fetch_add(4, Relaxed) // init = 0x1000
}
```
**Monotonic atomic counter, bump-only.** `nt_close` (exports.rs:1869)
removes the object from `state.objects` but never returns the handle
ID to a free list. **Recycling is structurally impossible.**
### (2) Lifecycle of 0x1454 in ours (deterministic across reruns)
| event | cycle | tid | LR | source |
|---|---|---|---|---|
| create | 0\* | 13 | 0x824a9f6c | NtCreateEvent (Event/Manual) |
| wait | 0\* | 13 | 0x824ac578 | do_wait_single |
| signal | 0\* | 5 | 0x824aa304 | NtSetEvent |
| wake | 0\* | 5 | — | wake_eligible_waiters/auto |
\* `cycle=0` is a separate audit-instrumentation gap
(`audit_entry` reads `scheduler.ctx(0).timebase` which is 0 in this
build); counts and ordering remain authoritative because rings are
append-only.
**Final state**: `waiters=0 signaled=true signal_attempts=1 waits=1
wakes=1`. Single create, single wait, single signal, single wake —
**fully consumed**. **0x1454 is not stuck.**
Created stack: `lr=0x822dfc94` (audit-041's sub_822DFC74 caller),
chained through `0x822e0344, 0x822d2ca4, 0x822de768, 0x821c4b1c`.
### (3) Lifecycle of 0xF80000CC family in canary
From `canary-bl-0x822DFC34.log` (audit-041) + `canary-create-0x8284DF1C.log`
(this audit, ~11.5 MB):
```
Added handle:F80000CC for XObject (fresh KEVENT slot)
NtDuplicateObject(F80000CC, ...) × 3
TRACE-PC-LR pc=822DFC34 r3=F80000CC (the wait, lr=822DFC0C)
NtClose(F80000CC) → Removed handle:F80000CC for XEvent
Added handle:F80000CC for XEvent (NEW KEVENT, SAME SLOT)
NtClose → Removed → Added × 4 more iterations
```
Recycling counts in 30s:
- `F8000098`: 130 reuses
- `F80000D0`: 95
- `F80000DC`: 71
- `F80000C0`: 10
- `F80000CC`: 5
Canary's `ObjectTable::AllocateHandle` is a slab/free-list allocator;
ours is bump-only. **Canary recycles heavily, ours never recycles.**
### (4) Decisive disambiguation
| | ours | canary |
|---|---|---|
| handle 0x1454 NtCreateEvent fires | 1 | n/a |
| handle 0xF80000CC `Added handle:` | n/a | 5+ in 30s |
| recycling? | **NO** | **YES** |
| 0x1454 wait completes? | **YES** (wakes=1) | n/a |
**Verdict: ROOT CAUSE IS NOT (A) HANDLE-RECYCLING.** Recycling is
structurally impossible in our impl. The signal lands on the same
object the waiter registered for.
**Sub-conclusion on audit-041**: audit-041 inferred a stall from
"7 pre-bl, 6 post-bl" lr-trace data, but ran with `--quiet` so
end-of-run audit dumps were suppressed. The post-bl miss is
explained by the wait's return path not crossing the post-bl PC
(KeWaitForSingleObject's wake-side context-restore can bypass it).
**Audit-041's "wait NEVER returns" premise is provisionally
falsified for handle 0x1454.**
### (5) Real wedge points (end-of-run handle waiter list)
Stalled handles in this session's run, all `<NO_SIGNALS_DESPITE_WAITS>`:
- `0x1004` Event/Manual (tid=11 parked)
- `0x1020` Event/Manual (tid=3 parked)
- `0x1040` Event/Auto (tid=5 via WaitMultiple)
- `0x1544` Event/Manual (tid=17 parked)
- `0x1578` Event/Auto (tid=19 parked)
- `0x12ac` Semaphore (tid=14, 15 parked)
- `0x10a0` Event/Auto + `0x10a4` Semaphore (tid=6 paired wait)
These are **γ-class missing-signaler** candidates; distinct from
0x1454.
## Bug-class refinement
- **δ-wakeup**: RULED OUT for 0x1454 (wake fired).
- **δ-namespace**: RULED OUT (single create, no aliasing).
- **Wedge migrates** to a different handle set — re-pivot needed.
## Sharp 4-dim cascade prediction (for audit-043 fix on real stalled handle)
- **A**: target handle's `signal_attempts` 0 → ≥1.
- **B**: stalled tid transitions Blocked → Ready/Exited.
- **C**: `<NO_SIGNALS>` count drops by ≥2 (cascading dependents).
- **D**: `swaps` past 2 OR `draws` 0 → >0. Probability: low — γ-cluster
plateau likely needs multiple gates.
## Recommended audit-043 (autonomous)
**Pivot off 0x1454.** Target the actually-stalled handles, ranked:
1. **`0x10a0` Event/Auto + `0x10a4` Semaphore on tid=6** —
Event+Semaphore pair = canonical worker-waits-for-job pattern.
2. **`0x12ac` Semaphore (2 waiters: tid=14, 15)** — `KeReleaseSemaphore`
source is the target.
3. **`0x1004` Event/Manual on tid=11** — earliest-created stalled
handle.
For each: `--trace-handles-focus=<handle>` → capture created stack
→ identify producer-side function. Canary cross-trace via
`--log_lr_on_pc=0x8284DF5C` (NtSetEvent) / `0x8284DDDC` (KeSetEvent)
filtering for equivalent canary handle.
**Bug class for audit-043**: **γ (missing signaler)** — primary
candidate. NOT δ-namespace, NOT δ-wakeup. Audit-040's
handle-namespace divergence appears benign at the level of 0x1454.
## Milestone status
- Tests: 645 (unchanged).
- Lockstep: instructions=100000004 unchanged (no source mods).
- Master HEAD: `d8766c6` (unchanged).
- Canary HEAD: `6de80dffe` (clean, post-revert).
- Patch budget: 0 LOC consumed (read-only audit).
- Discipline gate: 5/5 PASS.
- Session 3 of 10 budget consumed.
## Trace artifacts
- `audit-runs/audit-042-handle-lifecycle/probe.log` (15 KB) — ours run 1
- `audit-runs/audit-042-handle-lifecycle/probe-run2.log` (15 KB) — ours run 2 (determinism)
- `audit-runs/audit-042-handle-lifecycle/canary-create-0x8284DF1C.log` (11.5 MB) — canary NtCreateEvent fires (~452 in 35s window)
- Cross-ref: `audit-runs/audit-041-wait-site/canary-bl-0x822DFC34.log`
(existing) re-grepped for canary's `Added/Removed handle:` markers.

124
migration/claude-memory/project_xenia_rs_audit_043_record_zero_offset_2026_05_09.md Normal file
View File

@@ -0,0 +1,124 @@
# KRNBUG-AUDIT-043 — Record +0x00 writer identification (2026-05-09)
**Status**: READ-ONLY, master `d8766c6` unchanged, canary patch reverted at session close.
**Tests**: 645 (unchanged). **Lockstep**: instructions=100000004 (no source mods).
## Goal
Identify the writer of `+0x00` in records at `0x40542300/0x40542340/0x40542400/0x405424c0` in our impl and reconcile with canary's divergent value. Per audit-039, ours has inline-filename text "game" (`0x67616D65`); canary has handle `0xF80000B8`.
## Method
1. Mem-watch `0x40542300/04, 0x40542340/44, 0x40542400/04, 0x405424C0/C4` in our impl, `-n 500_000_000`.
2. Group writers by (PC, LR), look up containing fns in `sylpheed.db`.
3. Disasm writer fns + caller chain.
4. Apply audit-030 `--log_lr_on_pc` patch to canary; probe writer PC = `0x825F1080` (memcpy core) and pool-init PC `0x82152728` in canary.
## Key findings
### Writer attribution (our impl)
Mem-watch produced 92 events, 16 distinct (PC, LR) pairs.
The `0x67616D65` ("game") writes — the anomaly under investigation — fire **only** at:
- **PC `0x825F1080`, LR `0x825ED608`**, `store_len=8` (`stdu r7, 8(r3)` loop body of memcpy).
- 16 fires total across all 4 records.
Containing functions:
- `0x825F1000-0x825F10B4` = **memcpy** (classic dword `ldu/stdu` loop with fall-thru to byte tail).
- `0x825ED588-0x825ED660` = **memcpy_s wrapper** (`r3=dest, r4=destsize, r5=src, r6=srclen` → `bl memcpy(r3,r4=src,r5=len)` at `+0x7C`).
### The records are NOT records — they are **64-byte slots in a Sylpheed-managed pool allocator**
Walking the chain:
- The pool layout is built by `sub_82152728` (called from `sub_82152570`, called from `sub_821505D8` at boot).
- `sub_821505D8` allocates a ~58 MB region via `sub_824A8858` (size `0x03A723D0`, type `0x20000004`, alignment 4) — VirtualAlloc-style.
- `sub_82152728` chains free-lists in two blocks. **Block 2 is 64-byte-stride slots over a 1.25 MB span**: chain step `r11 += 0x40` until `r9 = r31 + 0x140000`. The records `0x40542300/40/400/4C0` ARE these 64-byte slots.
- The slot-size table (`0x82150610`+) lists the bucket sizes: 4, 16, 32, 64, 96, 128, 160, 192, 256.
The `0x67616D65` writer is **`std::basic_string::reserve_then_assign`** at `sub_8216E138`:
- Calls heap allocator `sub_8216D9C8` (returns one of the 64-byte pool slots).
- `bl memcpy_s` at `+0xC8` copies the source string ("game\\source3D\\Common.x...") into the slot.
So the 4 records are **transient std::string heap buffers**, not statically-laid-out resource records.
### Canary writer comparison (PC `0x825F1080`)
Applied `audit-030` LR-trace patch to canary, probed `pc=0x825F1080`:
- **94,945 fires in 25s**, never to address `0x40542xxx`.
- Top destinations (r3 prefix): `705D` (76674), `7033` (6642), `7036` (6254), `7043` (5952), `BC36` (1211), `BD17`, `B4Dx`, etc.
- Top LR distribution: `0x824AB1D4` (84,400), `0x824C7EF0` (9727), `0x824C27AC` (4880), `0x824C2760` (4880), `0x825ED608` (1,782), …
- Memcpy fires from `LR=0x825ED608` (matching our impl) **only 1,782× and never targets `0x40542xxx`**.
Pool-init probe `pc=0x82152728` in canary fires **once** with `r3=0xBC32C880` — canary's pool BASE address.
## Divergence — final interpretation
**Both impls run the same guest code** (`sub_82152728` initializes the same pool layout in both). The divergence is purely **virtual-address-space layout in the host allocator**:
- **Our impl**: VirtualAlloc-style backing returns address `~0x40541xxx` for the 58 MB pool → block-2 64-byte slots fall on `0x40542300, 40, 400, 4C0`.
- **Canary**: Same call returns `0xBC32C880` → block-2 slots fall on `0xBCxxxxxx` instead.
The **same guest virtual address `0x40542300` therefore backs DIFFERENT live data in the two emulators**:
- Ours: a 64-byte std::string heap buffer holding "game\\source3D\\Common.x..."
- Canary: a kernel object handle slot (or another structure entirely) where `+0x00 = 0xF80000B8`.
The "0xF80000B8 vs 'game'" comparison from audit-039 was therefore **not a comparison of equivalent data** — it was an artifact of comparing two emulators' memory at the same guest address while their respective allocators had returned that address for two different purposes.
The audit-040 "handle@+0x00=0xF80000B8" interpretation **stands but applies to canary's own use of that VA, not to a record class shared between impls**. There is **no missing/wrong write at +0x00 in our impl**; ours is correctly populating its own pool-slot's std::string.
## Bug class refinement
- **NOT a record-layout divergence** (no shared "record" class — disjoint allocations).
- **NOT a missing kernel write** (the +0x00 in canary is canary's own NotifyListener / kernel handle storage at *that* VA; ours legitimately puts a string there).
- **Underlying class = ε (allocator address-space divergence)**: same guest API call returns different host-side VAs in canary (0xBC) vs ours (0x40).
This invalidates the "record-by-VA cross-comparison" methodology used in audits 037/039/040 for the 0x40542300+ block. **Reading-error ledger update**: add a 12th entry — *VA-equality fallacy*: comparing two emulators' memory at identical guest VAs assumes both allocators return the same VA for the same logical allocation. Sylpheed's pool factory makes this assumption false in general.
## Recommended audit-044
**Pivot**: drop the "record at 0x40542300+" line of investigation entirely. The records do not exist as a shared structure.
Re-pivot to the **actually-stalled-handle** plan from audit-042:
1. Trace `0x10A0` (Event/Auto) + `0x10A4` (Semaphore) waited by tid=6. Producer chain via `--trace-handles-focus=0x10a0,0x10a4`.
2. Trace `0x12AC` (Semaphore, 2 waiters tid=14/15). KeReleaseSemaphore source.
3. Trace `0x1004` (Event/Manual on tid=11) — earliest-created stalled handle.
Each: get creator + signaler PC in our impl, map to canary equivalent via `--log_lr_on_pc` on `KeSetEvent` / `KeReleaseSemaphore` thunks.
**Discipline reminder**: cross-emulator VA equality is unreliable. When comparing memory contents, compare the *logical* allocation (resolve via the allocator that produced it), not the raw VA.
## Discipline gate (5/5 PASS)
1. Hypothesis explicitly tested (writer-of-+0x00 isolated; canary equivalence checked).
2. Canary patch applied (30 LOC audit-030 base) + reverted at session close (`git status` clean, config TOML restored).
3. xenia-rs source unmodified, no commit.
4. Single-step (data-gathering only, no fix attempt).
5. Trace files saved: `audit-runs/audit-043-record-zero-offset/{mem-watch.log, mem-watch.stdout, canary-825f1080-traces.txt.gz, audit-043-canary-poolinit.log}`.
## Status
- Tests: 645 (unchanged).
- Lockstep: instructions=100000004 (unchanged — no source mods).
- Master HEAD: `d8766c6` (unchanged).
- Canary HEAD: post-revert clean (working tree restored).
## Key PCs / LRs (cross-ref)
| Role | PC | LR | Containing fn |
|------|----|----|---|
| memcpy core (ldu/stdu loop) | `0x825F1080` | (varies) | `sub_825F1000` (memcpy) |
| memcpy_s wrapper | (calls memcpy at `0x825ED604`) | `0x825ED608` (return) | `sub_825ED588` (memcpy_s) |
| std::string assign w/ realloc | `0x8216E200` (call to memcpy_s) | (callers list 19) | `sub_8216E138` |
| pool-slot heap allocator | (entry) | — | `sub_8216D9C8` |
| pool free-list initializer | `0x82152728` | `0x82152634` | `sub_82152728` |
| pool factory (VirtualAlloc + init) | `0x821505D8`-`0x821506B8` | from `0x8280C42C` | `sub_821505D8` |
| std::string default ctor / assign | — | — | `sub_82454498` / `sub_82454580` |
## Canary pool base address
`r3 = 0xBC32C880` at sub_82152728 entry — canary's 58 MB pool starts here. Ours' equivalent base address backs the 0x40541xxx region (slot offsets land 0x40542300, 0x40542340, 0x40542400, 0x405424C0).

56
migration/claude-memory/project_xenia_rs_audit_044_m55_cluster_survey_2026_05_09.md Normal file
View File

@@ -0,0 +1,56 @@
---
name: AUDIT-044 M5.5 cluster reachability survey 2026-05-09
description: M5.5 typed-vptr BFS lifts audit-009 cluster from 0/321 static-reach to 41/321 indirect-reach (12.8%). Lift is surface-level — entry via 4 vtable methods on 2 vtables. Cluster's actual constructors (6 vptr writers) remain dead in BOTH views. Highest-leverage probe target: sub_8228F858 writer at 0x8228FAC8.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-044 (2026-05-09, READ-ONLY, master `7bc9e3a` unchanged)**: post-overhaul cluster reachability survey. Pure DuckDB queries on `/home/fabi/RE Project Sylpheed/xenia-rs/sylpheed.db` against M5.5 typed-vptr indirect BFS view `v_indirect_reachability_from_entry`. No xenia-rs binary executions, no canary patches.
## Numerics
- **Cluster `0x82285000-0x82294000`**: 321 fns total (308 pdata_validated)
- **Static-bl-only reach**: **0 / 321**
- **M5.5 indirect-vptr reach**: **41 / 321 (12.8%)** ← M5.5 lift
- **Globally**: static reach 1383 fns → indirect reach 4129 fns → M5.5 newly-reached **2746 fns** (matches MEMORY.md)
- **Audit-009 L1 PCs (6)**: only `sub_822919C8` becomes reachable (2-hop via `sub_82291C90` slot 1 of vtable `0x820a9c28`). Other 5 (`sub_82293448, sub_82288028, sub_82292D80, sub_822851E0, sub_82286BC8`) remain dead.
- **5 sub-buckets totally dead** (0x87/0x88/0x89/0x8d/0x92 in 0x82285000..0x82294000) = 131 fns = 41% of cluster
## Cluster vtable structure (M3)
Only **TWO** classes have methods inside the cluster:
- vtable `0x820a9c28` (`ANON_Class_F990DC4E`, length 3): slots 0/1/2 = `sub_82291740 / sub_82291BD0 / sub_82291C90`
- vtable `0x820aa024` (`ANON_Class_443BCBAF`, length 8): slot 0 = `sub_82293ED8` (other 7 outside cluster)
So 321 cluster fns but only **4 OOP-visible methods** (RTTI stripped, M3 sees anon classes only).
## How the 41 lift happens
Cluster bootstraps **transitively** from these 4 vtable methods. M5.5 sees external dispatchers (mostly cand_count=203 noise sites — "any of 203 tracked vtables") nominally landing in slot-1 of `0x820a9c28` or slot-0 of `0x820aa024`, then static-bl follows downstream. The cluster's **actual constructors** — 6 vptr-writer fns `sub_8228F858, sub_82293EC8, sub_82294110, sub_82294898, sub_822A0860, sub_822A0E90` — are **dead in both views** (no static caller, no indirect call). The cluster is reachable from outside but is never *instantiated* through a known top-down path.
## Audit-033 chain status
`sub_82451E20 / sub_82450720 / sub_82450638 / sub_821CB968 / sub_821CD458 / sub_821CBEA8` ALL indirect-reachable. Terminates at `sub_821CECF0 → sub_821C4988 → sub_821C4EB0` — **genuine orphans** (7-hop backward BFS finds zero reachable ancestor under any xref kind). Audit-033 saw probes hit `sub_82451E20` 62×/8s in ours vs 28×/50s wall in canary — busy-loop divergence already isolated; loop-exit gate remains the divergence target there.
## Audit-033 named callers status
`sub_82172BA0` (caller of `0x8228E138`) is dead in both views — not statically reachable, not indirect-reachable. M5.5 didn't bridge it (no vptr-write inference). Yet audit-033 saw it fire 2× canary / 1× ours. **The plain BFS misses these paths entirely** — likely because LR=`0x82172BF8` is reached via a dispatch that M5.5 marks cand_count=203 (noise) and the BFS prunes. Worth a sharper M5.5 follow-up later.
## Top-3 probe targets ranked
1. **`sub_8228F858` writer at PC `0x8228FAC8`** — the missing constructor for vtable `0x820a9c28` (the only fully-cluster-resident vtable). 2 callers `sub_82289FD0/sub_82285838` also dead. **Probe `--log_lr_on_pc=0x8228FAC8` in canary** to capture LRs. If fires: walk upward in DB. If doesn't fire in canary either: the cluster's UI subsystem isn't activated in canary at this boot horizon.
2. **`sub_822F1AA8`** — statically reachable, **685 outgoing ind_calls** including 4 distinct cluster targets (`0x822F1B4C → sub_82293ED8/sub_82291740`, `0x822F1C00 → sub_82291C90`, `0x822F1D58 → sub_82291BD0`). Highest-fanout statically-reachable function feeding the cluster. Probe `--lr-trace` on entry; check if any of 4 ind_call sites fire canary-vs-ours divergent.
3. **`sub_82172BA0` LR `0x82172BF8`** — confirm audit-033's 2× canary / 1× ours divergence holds post-overhaul; pivot to disasm of predicate inside.
## Cand_count precision note
M5.5's `indirect_dispatch_sites.candidate_count` is a useful precision indicator. **`cand_count ≤ 10` = actionable**, `cand_count = 203` = "any of 203 tracked vtables" = effectively noise for cluster-target ranking. Only **5 dispatch sites globally** have `cand_count=2` with a cluster target (`0x821E7BE8/D30/DA0/0x821E8344/0x8241F348` → vtable `0x820aa024 slot=5/6`). Future M5.5 work should filter by `cand_count` first.
## Methodology / ledger
No new reading-error ledger entry (still 12). Corroborates: cluster identity reframe (UI/save-game), audit-009 framing, audit-031/032 "pure this->vptr" claim, audit-033 chain.
Trace artifacts at `/home/fabi/RE Project Sylpheed/xenia-rs/audit-runs/audit-044-m55-cluster-survey/` — `survey.py`, `queries.sql`, `schema.txt`, `query_outputs/{q3_newly_reachable,q5_dispatch_sites,q6_cluster_vtables}.csv`. Master HEAD `7bc9e3a` unchanged. swaps=2 draws=0 plateau intact.
## Recommended AUDIT-045
Dispatch with: re-apply audit-030 `--log_lr_on_pc` patch (30 LOC, 4 files) to canary; probe `0x8228FAC8` (writer site) + `0x8228F858` (entry) + `0x82172BF8` (audit-033 LR); also `0x822F1B4C / 0x822F1C00 / 0x822F1D58` (sub_822F1AA8's 4 cluster-targeting ind_calls). Cross-check with our impl `--pc-probe` (-n 500M). Revert patch at session close.

64
migration/claude-memory/project_xenia_rs_audit_045_cluster_ctor_probe_2026_05_10.md Normal file
View File

@@ -0,0 +1,64 @@
---
name: AUDIT-045 cluster ctor probe + 13th reading-error class 2026-05-10
description: Falsified audit-044's "missing cluster constructor" hypothesis — sub_8228F858 vptr-write at 0x8228FAC8 fires 0× in canary too (50s wall) AND in ours (-n 500M). Cluster genuinely not instantiated at this boot horizon in either engine. T6 (audit-033 LR 0x82172BF8) confirms gateway chain entry→sub_8216EA68→sub_822F1AA8→sub_82172BA0 runs in both. New 13th reading-error class: probe-firing-granularity divergence — ours --pc-probe fires only at basic-block entry, canary --log_lr_on_pc per-instruction.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-045 (2026-05-10, READ-ONLY, master `7bc9e3a` unchanged, canary `6de80dffe` patch reverted clean)**: cluster constructor activation probe via re-applied audit-030 `--log_lr_on_pc` canary patch (30 LOC, 4 files). 6 target PCs probed in both engines.
## Headline (4 of 6 results)
| Tag | PC | Site | Canary | Ours | Class |
|-----|----|----|----|----|----|
| T1 | 0x8228FAC8 | vptr-write of vtable 0x820a9c28 in sub_8228F858 | **0** (50s) | **0** (-n 500M) | (c) neither — REFUTES audit-044 hypothesis |
| T2 | 0x8228F858 | entry of cluster ctor sub_8228F858 | **0** | **0** | (c) neither |
| T3-T5 | 0x822F1B4C/0x822F1C00/0x822F1D58 | ind_call sites in sub_822F1AA8 | 1/5/4646 | 0/0/0 | (b) but **artefactual** — reading-error #13 |
| T6 | 0x82172BF8 | post-bl PC inside sub_82172BA0 (audit-033 LR) | 2 (90s) | 1 | (a) **both fire** — gateway chain runs |
## Decisive falsifications
1. **T1=T2=0 in CANARY** — refutes audit-044's "missing cluster ctor is the bootstrap divergence" hypothesis. Cluster's 6 vptr-writer ctors (`sub_8228F858, sub_82293EC8, sub_82294110, sub_82294898, sub_822A0860, sub_822A0E90`) fire 0× in canary at 50s — not just in ours. Consistent with RECONCILE-B: Linux Vulkan/XCB host-presenter stalls before front-end-UI state machine advances; Lutris Windows reaches frame 72/186 vs Linux 42/186. The cluster genuinely **isn't activated at this boot horizon in either engine**.
2. **T6 fires in both** with exact LR-walk verified-direct chain in ours:
```
frame 0: pc=0x82172BF8 in sub_82172BA0 (post-bl)
frame 1: lr=0x821744cc
frame 2: lr=0x822f1d5c in sub_822F1AA8 +0x2B4 (post T5 ind_call)
frame 3: lr=0x8216ee14 in sub_8216EA68 +0x3AC (post bl 0x822F1AA8)
frame 4: lr=0x824ab8e0 in entry_point +0x198
```
Static edges verified: `0x8216EE10 bl 0x822F1AA8` direct from sub_8216EA68; entry_point→sub_8216EA68 direct. **Gateway path entry→sub_8216EA68→sub_822F1AA8→sub_82172BA0 runs in both engines.** What doesn't run is the cluster-ctor branch off this gateway. The ind_call at 0x822F1D58 dispatches on r3=`0xBC22C910` singleton (canary, fires 4646× hot) whose vtable is NOT 0x820a9c28 (cluster). Cluster vtables are statically 2-of-203 candidates at each ind_call but at this horizon never materialise as live targets.
## Reading-error ledger — 13th entry: probe-firing-granularity divergence
xenia-rs `--pc-probe` fires inside worker_prologue at **basic-block entry only** (single `kernel.fire_ctor_probe_if_match(hw_id, mem)` check in `crates/xenia-app/src/main.rs:2200`). Canary's audit-030 `--log_lr_on_pc` patch emits `Trap(100)` **inline in HIR** for every guest instruction whose PC matches — fires per-execution. Comparing fire counts at mid-block PCs (ind_call instructions like 0x822F1D58, store-multiple, mid-loop bodies) systematically yields ours=0 even when code executes equivalently. **Mitigation**: prefer function-entry PCs (always block-entry in both engines) or post-bl return PCs (block-entry by JIT construction); for mid-block PCs, validate via back-chain reachability of the containing function rather than fire-count parity. Joins existing 12 ledger entries.
## DB usage caveat (NOT a data bug)
`v_call_graph` filters by `xrefs.source` (= instruction PC of the BL) rather than `source_func`. Querying "callees of sub_8216EA68" via the view yields 0; querying via `xrefs.source_func` correctly yields 24 static callees including `sub_822F1AA8`. **Future audits**: prefer `xrefs.source_func` for caller-set queries.
## Strategic position
Audit-009 cluster activation is genuinely past Linux Debug canary's reach (3 horizons confirmed: VERIFY-A 35s, audit-034 5min, audit-039 15min, audit-045 50s on more PCs — all 0 fires for cluster ctors). To capture cluster activation in canary, we'd need to bypass the Linux Vulkan/XCB host-presenter — that means rebuilding canary under Wine/Lutris (large investment).
ALTERNATIVE pivot: focus on the audit-034/035 frame-chain divergence at sub_82450720 — that's a concrete, reachable, divergent code path (5/5 ours iter vs 3.75/5 canary). Audit-035's slot-table writer divergence (canary 0xBC3xxxxx physical-heap pointers vs ours 0x4024xxxx v40-bump) is a candidate. **Probe predicate `0x82450904` in both engines** to capture loop-exit cr0.eq=1 firing (audit-046 path B).
## Recommended AUDIT-046 (path B preferred)
Probe loop-exit `bne` predicate at PC `0x82450904` (audit-034's identified divergence in `sub_82450720+0x160..+0x1F4`) with `--log_lr_on_pc=0x82450904` in BOTH engines, capturing iteration count via cycle delta within each loop entry.
Sharp 4-dim cascade prediction:
- A: predicate at 0x82450904 fires with `cr0.eq=1` on iter 3-4 in canary, never in ours
- B: stalled-tid state unchanged (renderer plateau is upstream of audit-009)
- C: sub_82451E20 over-firing ratio 5.5× (62× ours / 28× canary in audit-033) drops toward 1×
- D: `draws>0` unlikely in this single-step fix (audit-009 cluster is upstream-blocked)
Cost: 1 PC × 50s canary + 1 ours run = ~5 min runtime + analysis. Modest.
Path A (fallback): rebuild canary under Wine/Lutris (Windows host stack) to bypass Vulkan/XCB block; rerun T1/T2 there. Larger investment.
## Discipline
xenia-rs HEAD `7bc9e3a` unchanged; canary HEAD `6de80dffe` clean (`git status --short` empty for tracked); patch saved at `audit-runs/audit-045-cluster-ctor-probe/canary-patch.diff`; raw probe logs preserved. Tests count untouched.
Trace at `audit-runs/audit-045-cluster-ctor-probe/` (8 canary logs + 12 ours logs + findings.md + canary-patch.diff).

48
migration/claude-memory/project_xenia_rs_audit_046_loop_exit_2026_05_10.md Normal file
View File

@@ -0,0 +1,48 @@
---
name: AUDIT-046 loop-exit predicate falsification 2026-05-10
description: Falsifies audit-035's slot-pointer-region divergence as causally responsible AND audit-034's "canary 3.75/5 vs ours 5/5" loop iter divergence. Both engines run 5/5 iters at sub_82450720+0x160..+0x1F4 and fall through to no-match exit. Slot-table region divergence (canary 0xBC3xxxxx vs ours 0x4024xxxx) is REAL but behaviorally inert — predicate compares within each engine's own heap region.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-046 (2026-05-10, READ-ONLY, master `7bc9e3a` unchanged, canary `6de80dffe` clean)**: probed loop-exit predicate at PC `0x82450904` inside `sub_82450720+0x160..+0x1F4`. Re-applied audit-030 patch verbatim from audit-045's saved diff.
## Falsifications
1. **Audit-035's slot-pointer heap-region divergence as causal**: REFUTED. Slot table at `0x828F3BD4` in ours has `0x4024xxxx` v40-bump pointers (slots 1/2/4: 0x4024A240/0x4024AEE0/0x4024A300, all size=8); slot 0 zero; slot 3 zero (audit-035's "over-cycled 0..0xB" stabilized). Canary has `0xBC3xxxxx` physical-heap pointers per audit-035. The predicate at 0x82450904 compares sub_82451E20's vptr-walk return (LHS) vs slot-local sum (RHS). **Both LHS and RHS originate from the same heap region within a given engine**, so the cross-engine address-space difference is internally consistent and **cancels as a divergence cause**. The region split is REAL but BEHAVIORALLY INERT here.
2. **Audit-034's "canary 3.75/5 vs ours 5/5" loop-iteration divergence**: REFUTED at current revision. Canary 70s probe `0x82450904` = 140 fires; canary 70s probe `0x82450918` (loop-completion no-match exit) = 22 outer-call completions; ratio 140/22 = **6.4 fires per outer call** ≈ 5+ iters/call when accounting for fallthrough fires. Ours single-run probe `0x82450908` (post-bne block-entry, fires every iter that fails) = **80 fires** = 16 outer calls × 5 iters/call exactly. **Both engines exhibit identical 5/5 loop shape with 0 early matches**. Audit-034's earlier measurement was either pre-overhaul or stale.
## Reading-error class 13 reconfirmed (mid-block PC unprobeable in ours)
`0x82450904` is the `bne` instruction itself (mid-block); ours `--pc-probe` only fires at basic-block entry → 0 fires in ours despite hot execution. Workaround used: probe block-entry alternatives `0x82450890` (loop-back top), `0x82450908` (post-bne fall-through), `0x8245092C` (predicate-match exit), `0x82450918` (loop-completion no-match exit). Cross-validated: `0x82450908` = 80 fires (post-fail-increment) = 16×5; `0x82450918` = 16 fires (outer completions) = 16×1; ratio 5/1 confirms 5/5 iters/call. This handles AUDIT-045's reading-error #13 properly — a confirmed working pattern.
## What this means strategically
The audit-035/036 frame-chain divergence at sub_82450720 is now triple-refuted as a causal target:
- Audit-036 already refuted "η-class record-layout divergence as stated" (refined to ε-class heap-region per audit-035)
- Audit-043 refuted ε-class heap-region as "missing/wrong write at +0x00" (12th reading-error class: VA-equality fallacy)
- Audit-046 refutes ε-class heap-region as causally responsible at predicate 0x82450904
The slot-table divergence is real DATA but doesn't gate any predicate behavior. **Drop sub_82450720 chain entirely as critical-path target.**
## Recommended AUDIT-047
**Option C (preferred): γ-cluster handle wedges per audit-042**. Concrete stalled handles in our impl at end-of-run:
- `0x10A0+0x10A4` (worker Event+Sema pair, tid=6)
- `0x12AC` (Semaphore with 2 waiters, tid=14,15)
- `0x1004` (Event/Manual, tid=11)
- `0x1020`, `0x1040`, `0x1544`, `0x1578` (additional NO_SIGNALS_DESPITE_WAITS)
These are γ-class missing-signaler bugs — concrete and reachable. Approach: dump full handle table state at -n 500M; for each wedge entry, capture create-LR + wait-LR + nearest-expected-signaler from caller chain. Cross-check against canary's `KeSetEvent`/`NtSetEvent`/`KeReleaseSemaphore` calls (need handle-namespace δ-class mapping per audit-040: ours `0x12AC` ↔ canary `0xF8000xxx` for the corresponding object).
Sharp cascade prediction:
- A: signal_attempts on the wedged handle 0 → ≥1
- B: stalled tid state Blocked → Ready
- C: `<NO_SIGNALS>` count drops ≥2
- D: `swaps>2` OR `draws>0` UNKNOWN — γ-cluster typically plateaus on a sister wedge, low cascade probability per audit-042
Cost: 1 ours run + 1-2 canary probes = ~10 min runtime + analysis.
## Discipline
xenia-rs HEAD `7bc9e3a` unchanged; canary HEAD `6de80dffe` clean tree confirmed. Patch reverted. Tests count untouched. Trace at `audit-runs/audit-046-loop-exit/{canary-0x82450904,canary-0x82450918,canary-0x82450934,ours-loop-probe,ours-loop-detailed,ours-entry-probe}.{log,err}` + `slot-table-dump-ours.log` + `canary-patch.diff`.

68
migration/claude-memory/project_xenia_rs_audit_047_gamma_wedges_2026_05_10.md Normal file
View File

@@ -0,0 +1,68 @@
---
name: AUDIT-047 γ-cluster handle wedges + signaler reachability 2026-05-10
description: 10 NO_SIGNALS_DESPITE_WAITS handles inventoried; per-wedge create-LR/wait-LR/expected-signaler tabulated. Best near-reachable signaler `sub_8245AD00` is statically reachable BUT its callers sit in audit-009 unreachability island. KeReleaseSemaphore = 0 ours / 73,914 canary, all from PC `0x824D229C` = sub_824D21F0+0xAC on r3=0x828A3230 (XAudio mixer) — already-known AUDIT-032 audio host-pump gap. Discipline 3/5 PASS, D dim = NO.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-047 (2026-05-10, READ-ONLY, master `7bc9e3a` unchanged, canary `6de80dffe` clean)**: γ-cluster handle wedge inventory + signaler reachability cross-check. End-of-run dump from xenia-rs `-n 500M --trace-handles`; canary KeReleaseSemaphore probe via re-applied audit-030 patch.
## Per-wedge table (10 wedges + XAudio mixer)
| Handle | Kind | tids | wait-fn | reach (s/ind) | best-sig nearby | sig reach | priority |
|---|---|---|---|---|---|---|---|
| 0x1004 | Event/M | 11 | sub_82178960 | N/N | sub_82174AF8 | N/Y | medium |
| 0x1020 | Event/M | 3 | sub_82181838 | Y/Y | sub_821819A8 | N/Y | medium |
| 0x1040 | Event/A | 5 | sub_82450A68 | N/N | **sub_82450218** | **Y/Y** | high |
| 0x10A0 | Event/A | 6 | sub_82458B90 | N/N | **sub_8245AD00** | **Y/Y** | high |
| 0x10A4 | Sema | 6 | sub_82458B90 | N/N | sub_8245AD00 | Y/Y (8 sigs / 5 wakes — wake-eligibility issue) | high |
| 0x12AC | Sema | 14,15 | sub_822C6878 | N/Y | sub_822C8B50 | N/Y | medium |
| 0x1530 | Timer/A | 16 | sub_824560F8 | Y/Y | sub_8245AD00 | Y/Y | high |
| 0x1534 | Event/A | 16 | sub_824560F8 | Y/Y | sub_8245AD00 | Y/Y | high |
| 0x1544 | Event/M | 17 | sub_82170438 | N/N | sub_82174AF8 | N/Y | medium |
| 0x1578 | Event/A | 19 | sub_823DDB58 | N/N | (none in ±32KB) | – | low |
| 0x828A3230 | Sema (XAudio) | 10 | sub_824D2940 | N/N | sub_824D21F0 | N/N | already named (AUDIT-032) |
**Of 125 total signal-source fns** (11 direct + 114 via wrappers `sub_824AA2F0` NtSetEvent / `sub_824AB158` NtReleaseSemaphore), only `sub_8245AD00` and `sub_82450218` are statically reachable AND nearby to wedge wait-fns. **sub_8245AD00 covers 4 wedges** (0x10A0, 0x10A4, 0x1530, 0x1534) — highest priority by coverage.
## Signaler call-count comparison (90s canary vs ours 500M-instr)
| API | Ours | Canary | Note |
|---|---|---|---|
| **KeReleaseSemaphore** | **0** | **73,914** | All from PC `0x824D229C` = sub_824D21F0+0xAC; all r3=0x828A3230 (XAudio) |
| KeSetEvent | 1 | (low) | – |
| NtSetEvent | 3,334 | 1 | inverse — wrapper-path active in ours |
| NtReleaseSemaphore | 393 | 1 | inverse — wrapper-path active in ours |
| NtWaitForSingleObjectEx | 1,489,791 | – | – |
The 0-vs-73,914 KeReleaseSemaphore divergence is on the XAudio mixer Semaphore, signaled from `sub_824D21F0`. **This is exactly the AUDIT-032 audio host-pump gap** — canary uses a host-side WorkerThreadMain to drive `sub_824D21F0` directly via `processor_->Execute(callback_pc=0x824D6640, args)` without a guest call site. Ours's `XAudioRegisterRenderDriverClient` correctly registers the callback but does NOT spawn a host worker thread to pump it. This is a known correctness gap, NOT a new finding.
## Convergence pattern (CRITICAL methodological observation)
All HIGH-priority wedges (`sub_8245AD00` covering 0x10A0/0x10A4/0x1530/0x1534) share a single fact: **the signaler is reachable, but its CALLERS are unreachable**. They sit in the same audit-009 unreachability island that all prior renderer-hunt audits (009/016/017/020/021/026/027/029/031/032/033/034/035/039/044/045/046) converge on.
**Implication**: γ-cluster wedge fixes can't open up renderer/draws-cascade independently. They drop NO_SIGNALS counts (B+C cascade dims succeed) but D=draws>0 fails because the unreached island is upstream of every concrete wedge.
## Discipline gate verdict (sub_8245AD00 candidate)
- (a) Named bug class with concrete evidence: γ (signaler reachable, callers in unreached island). **PASS w/ caveat**.
- (b) LOC budget ≤ 80: **FAIL** — making sub_8245AD00 fire requires unsticking the front-end-UI cluster = audit-009 plateau. Not a bounded fix.
- (c) Sharp 4-dim cascade: A=signal_attempts 0→8+, B=tid 6/16 Blocked→Ready (high conf), C=NO_SIGNALS 10→6 (4 wedges share sub_8245AD00); **D=swaps>2 OR draws>0: NO** (front-end UI cluster ≠ renderer per RAPID-SURVEY-Q4 reframe). **PARTIAL.**
- (d) No renderer/GPU mods: PASS.
- (e) Lockstep determinism preserved: PASS.
3/5 PASS, 2/5 FAIL/PARTIAL.
## Strategic floor reached
Linux Debug canary's reach genuinely caps at "intro-video frame ≈ 42/186; cluster activation never triggered." Four autonomous-mode audits (044-047) converge on this. Audits 045 confirmed the cluster ctors don't fire in canary either; audit 046 confirmed the slot-table chain is behaviorally inert; audit 047 confirms γ-cluster wedges all hit the same island.
**To make further progress on draws>0**, ONE of these is required:
1. **Wine/Lutris canary build** to bypass Vulkan/XCB Linux presenter block → reach post-intro state machine and capture cluster activator naming
2. **Audio host-pump fix landed** (AUDIT-032) — won't open renderer but closes the largest known canary-only export gap (KeReleaseSemaphore 0→non-zero); ~60-120 LOC mirroring canary `apu/audio_system.cc:84-159`
3. **Different probing technique** — e.g., guest-thread injection to force-call cluster ctor entry points and observe what guard predicates fail (high-risk, prone to causing HW-thread hijacks per APUBUG-PRODUCER-001)
Within Linux Debug + READ-ONLY discipline, autonomous mode has reached diminishing returns. Recommended: hand-back to user for path selection.
## Discipline
xenia-rs HEAD `7bc9e3a` unchanged; canary HEAD `6de80dffe` clean (`git status --short` empty). Patch reverted via `git checkout` of 4 files. Tests count untouched. Trace at `audit-runs/audit-047-gamma-wedges/{wedge-analysis.csv, wedge-analysis.txt, ours-end-state.log, ours-end-state.err, canary-KeReleaseSemaphore-0x8284E49C.log (32MB), canary-patch.diff}`.

112
migration/claude-memory/project_xenia_rs_audit_048_audio_host_pump_fix_2026_05_10.md Normal file
View File

@@ -0,0 +1,112 @@
---
name: AUDIT-048 audio host-pump fix LANDED 2026-05-10
description: Path 2 of post-autonomous handback. Implemented dedicated audio worker thread per client (mirroring canary apu/audio_system.cc:84-159 in xenia-rs's threading model). 75 net LOC across 4 files. Cascade A/B/D from AUDIT-032 prediction CONFIRMED. swaps regressed 2→1 (degenerate splash lost) but boot phase advanced past audio-wait stall into Stfs/Xam content/crypto init. draws unchanged at 0 (expected per AUDIT-032 — audio≠renderer). Working tree dirty; user re-baselines goldens separately.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-048 (2026-05-10, IMPLEMENTATION LANDED in working tree, NOT COMMITTED)**: AUDIT-032 audio host-pump fix per Plan B (dedicated worker thread, not victim hijack). Mirrors xenia-canary's `apu/audio_system.cc:84-159` `WorkerThreadMain` pattern in xenia-rs's threading model.
## Files modified (4 crate files, no goldens, no canary)
```
crates/xenia-app/src/main.rs | 94 +- (try_inject_audio_callback rewrite + flag-default semantics)
crates/xenia-kernel/src/exports.rs | 82 +- (xaudio_register_render_driver spawns dedicated worker)
crates/xenia-kernel/src/state.rs | 24 +- (xaudio_tick_enabled default true)
crates/xenia-kernel/src/xaudio.rs | 41 + (worker_refs field + helpers)
```
107 insertions, 32 deletions = **75 net non-comment LOC**, well under AUDIT-032's 60-120 budget.
## Design (Plan B — chosen over Plan A "just enable flag")
The pre-existing `--xaudio-tick` flag worked via `try_inject_audio_callback` which **hijacked a random Ready/Blocked guest thread** as victim. Documented in flag's docstring as "shifts boot trajectory enough to regress swaps=2→1" — flagged as APUBUG-PRODUCER-001 per AUDIT-032.
**Plan B**: dedicated guest worker thread per registered client, never hijack other threads.
1. `XAudioRegisterRenderDriverClient` (exports.rs:3074): after `xaudio.register()` succeeds, also `allocate_thread_image` + `state.scheduler.spawn(SpawnParams{ entry=callback_pc, start_context=wrapped_callback_arg, create_suspended=true, ... })`. Immediately mark spawned thread `Blocked(WaitAny { handles: vec![0xF000_0000 | i], deadline: None })` — synthetic handle outside normal allocator range (≥0x1000), not registered in state.objects, so wake_eligible_waiters never finds it. Stores `ThreadRef` in new field `XAudioState::worker_refs[i]`.
2. `try_inject_audio_callback` (main.rs:3261): replace random-victim selection with `let target_ref = kernel.xaudio.worker_refs[client_index]?`. Existing `SavedCallbackCtx::capture` + PC injection + `lr=LR_HALT_SENTINEL` + `gpr[3]=wrapped_arg` unchanged. Existing restore path (main.rs:2218) re-blocks worker on synthetic when callback returns to LR_HALT.
3. `state.rs:309`: `xaudio_tick_enabled` default `true`. CLI flag becomes force-on/off override.
## Cascade verification (500M-instr validation)
Pre-fix baseline = `audit-runs/audit-047-gamma-wedges/ours-end-state.log` (-n 500M, ~3 min wall).
Post-fix log = `audit-runs/audit-048-audio-host-pump/validation-500m.log`.
| Dim | Predicted | Observed | Pass? |
|-----|-----------|----------|-------|
| A | tid=9 leaves Blocked(WaitAny [0x828A3254]) | tid=9 was Blocked at `pc=0x824d28d0` → now Ready at `pc=0x824d1404 lr=0x824d22b4` | ✅ |
| B | tid=10 leaves Blocked(WaitAny [0x828A3230]) | tid=10 was Blocked at `pc=0x824d2990` → now Ready same `pc/lr` as tid=9 | ✅ |
| C | XAudioSubmitRenderDriverFrame 0→non-zero | `XAudioSubmitRenderDriverFrame=0` (Sylpheed hasn't reached submit phase in 500M); `XAudioGetVoiceCategoryVolumeChangeMask=1` NEW — mixer setup path executed | ◐ partial |
| D | KeReleaseSemaphore 0→non-zero | **KeReleaseSemaphore=1** (was 0); xaudio.callback.delivered=1 | ✅ |
**Bonus**: audit-042's "real wedge" handles `0x10A0+0x10A4` worker pair on tid=6 ALSO went Blocked→Ready as a downstream effect.
## Boot trajectory shift (the meaningful-progress signal)
Kernel call counts changed dramatically post-fix vs pre-fix audit-047 baseline:
| Counter | Pre-fix | Post-fix | Delta |
|---------|--------:|---------:|-------|
| NtWaitForSingleObjectEx | 1,489,791 | 30 | **-99.998%** |
| NtSetEvent | 3,334 | 68 | **-98%** |
| NtCreateEvent | 411 | 104 | -75% |
| NtReleaseSemaphore | 393 | 101 | -74% |
| KeReleaseSemaphore | 0 | 1 | NEW |
| StfsCreateDevice | 0 | 1 | NEW (Secure Transacted File System mount) |
| ObCreateSymbolicLink | 0 | 1 | NEW (VFS symlink) |
| XamContentCreateEnumerator | 0 | 1 | NEW (savegame discovery) |
| XamEnumerate | 0 | 1 | NEW (content enum) |
| XamTaskSchedule | 0 | 1 | NEW (task scheduler) |
| ExCreateThread | 0 | 10 | NEW (10 new threads) |
| KeSetAffinityThread | 0 | 7 | NEW |
| NtCreateSemaphore | 0 | 4 | NEW |
| NtWaitForMultipleObjectsEx | 0 | 94 | NEW |
| XeCryptSha | 0 | 1 | NEW (cryptography) |
| XeKeysConsolePrivateKeySign | 0 | 1 | NEW (console keys) |
The system **left the audio-wait busy loop** (1.4M waits → 30) and **entered the savegame/content/crypto init phase**. New executables/tasks/threads spawning. Cryptographic operations firing. Storage device created.
## swaps + draws
- **swaps: 2 → 1**. Documented regression. Pre-fix swaps=2 came from a degenerate splash repeat (system idle on audio waits, GPU producing splash frames in tight loop). Post-fix loses one splash repeat (splash period interrupted by audio worker activity) but main thread advances PAST splash entirely. New stall: tid=1 main `Blocked(WaitAny [4736=0x1280])` at `pc=0x824ac578` — different wedge from pre-fix's tid=1 stall.
- **draws: 0 → 0**. EXPECTED per AUDIT-032 methodology correction. Audio gate ≠ renderer gate. The audit-009 cluster (front-end UI / save-game / mission-select / HUD) remains independently blocked. Renderer plateau not crossed.
## Build/test status
- `cargo build --release`: succeeds (clean 14.06s, incremental 6.57s). No new warnings.
- `cargo test --release -p xenia-kernel --lib`: 127/127 pass (incl. 14 xaudio tests + 4 register-driver export tests).
- `cargo test --release -p xenia-app --lib`: 5/5 non-ignored pass.
- Lockstep goldens (`sylpheed_n2m.json`, `sylpheed_n50m.json`): `#[ignore]`-gated, NOT re-baselined this session per task brief. They WILL drift on this fix; user re-baselines as separate commit.
## Open follow-ups (NOT in scope this session)
1. **Re-baseline lockstep goldens** under audio-on default. Single commit, isolated.
2. **Probe new wedge** — tid=1 main now Blocked on handle 0x1280 (=4736) at `pc=0x824ac578`. Identify what 0x1280 is, what's expected to signal it. Likely the next γ-class wedge per audit-047 pattern.
3. **Renderer cluster (audit-009)** — with audio unblocked, longer-horizon traces (≥1B instr) may now reach previously-gated cluster L0 PCs. Worth a 5B-instr run to see if cluster activates within ours's reach now.
4. **XAudioSubmitRenderDriverFrame** — currently a no-op stub (`exports.rs:3127-3133`). Would need real impl for game audio to render. Not blocking renderer, but a known gap.
5. **Worker hygiene** — worker thread is left parked on synthetic handle when client unregisters; Sylpheed never unregisters during boot but multi-stream titles might hit this.
6. **Multi-client untested** — Sylpheed registers exactly 1 client. Per-slot data layout should compose to 8 but verify on a multi-stream title.
## Strategic position post-AUDIT-048
Path 2 (audit-032 audio fix) **DONE**. Cascade A/B/D succeed. Boot trajectory advanced past audio stall into a fundamentally new phase (Stfs/Xam content/crypto). swaps regressed 2→1 (degenerate splash) but main thread advanced past splash. draws unchanged (expected).
User decision: did audit-048 produce "meaningful progress"? Argument for YES — boot phase fundamentally advanced; previously-blocked tids (6/9/10/12) are now Ready; new kernel paths active. Argument for NO — `swaps>2 / draws>0` plateau still uncrossed; one of the two splash swaps lost.
If "yes": next critical-path target is the new tid=1 stall on handle 0x1280 OR a longer-horizon run to see if renderer cluster activates. If "no": queue Path 1 (Wine/Lutris canary build) for a new oracle.
## Trace artifacts
- `audit-runs/audit-048-audio-host-pump/findings.md` (worker agent's writeup)
- `audit-runs/audit-048-audio-host-pump/validation-500m.log` (95 KB, 879 lines)
- `audit-runs/audit-048-audio-host-pump/diff-summary.txt` (17 KB, full diff of 4 files)
## Discipline
- xenia-rs HEAD `7bc9e3a` UNCHANGED — working tree dirty (4 crate files + audit-findings.md + audit-runs/audit-048-*).
- xenia-canary HEAD `6de80dffe` not touched (this session's work was xenia-rs only).
- No commits. No goldens re-baselined.
- Tests count: kernel 127/127, app 5/5 non-ignored.
- Lockstep digest WILL move (intentional fix); goldens deferred.

83
migration/claude-memory/project_xenia_rs_audit_049_tid1_stall_2026_05_10.md Normal file
View File

@@ -0,0 +1,83 @@
---
name: AUDIT-049 tid=1 stall on 0x1280 — same island one layer deeper 2026-05-10
description: Post-AUDIT-032 the new front-line stall (tid=1 main on handle 0x1280 = THREAD handle for tid=13) is a thread-join. tid=13 itself stalls on event 0x1288 created in sub_821CB030+0x128 (silph::GamePart_Title::UImpl::*) — front-end UI cluster, audit-009 island. Worker cluster's 5 NtSetEvent callers all statically unreachable. Discipline gate 3/5 PASS, same as AUDIT-047. 5th consecutive audit (044/045/046/047/049) converging on the same unreachability island.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-049 (2026-05-10, READ-ONLY, master `25704c5` unchanged)**: post-AUDIT-032 wedge analysis — investigates the new tid=1 main stall that emerged after the audio host-pump fix unblocked the boot trajectory.
## Wedge identity
- **Handle 0x1280**: NOT an event/sema/timer — it's a **Thread handle** for `tid=13` (`Thread(id=13, exit=None)`). tid=13 was created by `ExCreateThread` with entry `0x821748F0` and start_ctx `0x4024a640`.
- **tid=1's wait**: at `pc=lr=0x824ac578` inside `sub_824AC540` = the **NtWaitForSingleObjectEx thunk**. Reached via alias `sub_824AA330` (KeWaitForSingleObject, alertable=0). Caller chain: `sub_82173990+0x2D0` (a thread-join helper) ← `sub_822F1AA8` ← `sub_8216EA68` (vtable=`0x820a183c`, class `AVSilph@silph`, top-level `silph::Silph`).
- **tid=1 is doing a THREAD JOIN** — waiting for tid=13 to exit.
## Sub-stall (the actual bug)
tid=13 itself stalls on **handle 0x1288 = Event/Auto**, created at `sub_821CB030+0x128 (0x821CB158)` via NtCreateEvent thunk `sub_824A9F18`. Pattern:
1. tid=13 creates event 0x1288, stores ptr at `[r31+92]` and `[r31+96]`
2. Submits work via `bl 0x82452DC0` (work-submitter, passes event-handle ptr in r6)
3. Waits on 0x1288 INFINITE
4. The work-submitter's callback should `NtSetEvent(0x1288)` to wake tid=13
5. The callback never fires
tid=13 create-chain (top-down):
- thread entry `sub_821748F0`
- ← `sub_821C4EB0` (vtable `0x820a3e00` = `UImpl@GamePart_Title@silph`)
- ← `sub_821CC3F8` (vtable `0x820a3dc8` = `AVGamePart_Title@silph`)
- ← `sub_821CBA08`
- ← `sub_821CB030` — creates event 0x1288, submits work, waits
**ALL of this chain is in the audit-009 cluster** (`0x82285000-0x82294000` neighbors per RAPID-SURVEY's reframe — front-end UI / save-game / mission-select / HUD).
## Static signaler enumeration
**5 NtSetEvent direct callers in worker cluster `0x82450000-0x8245C000`** are the signaler candidates:
| Candidate | static reach | indirect reach | priority | note |
|---|---|---|---|---|
| `sub_82452DC0` (work-submitter) | YES | YES | high | depth-5 transitive call set INCLUDES `sub_824AA2F0` (NtSetEvent wrapper) — work chain *should* signal |
| `sub_82458A70` | NO | YES | medium | called from sub_82450550 / sub_82450B68 worker pool |
| `sub_824566D0` | NO | YES | medium | only via indirect dispatch |
| `sub_82458B90` / `sub_824500E8` | NO | NO | low | unreachable; sub_82458B90 is itself a wait-fn for AUDIT-047 wedges 0x10A0/0x10A4 |
| `sub_82453910` (post-wait pulse) | YES via sub_82173990 | NO | not-applicable | called from tid=1's join AFTER wait completes — can't be the signaler |
The tight tid=13 region (`0x821C0000..0x821CD000`) contains **ZERO callers** of any signaling kernel API. All `silph::*` / `GamePart_Title::*` / `UImpl::*` callers are statically AND indirectly **unreachable from `entry_point`** — same audit-009 island that has blocked every renderer-hunt audit.
## Discipline gate verdict
- (a) Bug class: **γ-cluster (missing-signaler) compounded with η-island (caller unreachable)**. PASS w/ caveat.
- (b) LOC budget ≤ 80: **FAIL** — making the worker chain fire requires unsticking `silph::Silph::*` → `silph::GamePart_Title::UImpl::*` upstream state-machine bring-up. Not bounded.
- (c) Sharp 4-dim cascade prediction: A=signal_attempts on 0x1288 0→≥1 (IF worker fires); B=tid=1 unblock probable on A; C=NO_SIGNALS drops 1+; **D=swaps>1 OR draws>0: NO** (same RAPID-SURVEY-Q4 reframe — front-end UI cluster ≠ renderer). PARTIAL.
- (d) No renderer/GPU mods: PASS.
- (e) Lockstep determinism preserved: PASS.
**3/5 PASS, 2/5 FAIL/PARTIAL** — same verdict as AUDIT-047.
## Strategic position
This is the **5th consecutive autonomous-mode audit** (044, 045, 046, 047, 049) to converge on the same audit-009 unreachability island. The AUDIT-032 audio fix advanced the boot trajectory ONE LAYER deeper:
- Pre-fix: spinning on audio waits, splashing twice
- Post-fix: spawned `silph::GamePart_Title::UImpl` init thread → blocked on its work-submit event
But the new front-line stall is in the **same cluster** RAPID-SURVEY-Q4 named, just one step further in the boot. The worker-cluster activator that should fire `sub_82452DC0`'s callback is not running for the same reason audit-009's L1 PCs don't fire — the cluster isn't bootstrapped.
**AUDIT-047's strategic-floor conclusion stands: Linux Debug canary's reach is the gate.** To make further progress, ONE of:
1. **Wine/Lutris canary build** for new oracle (path 1 from autonomous-run synthesis)
2. Different probing technique (HW-thread injection, high risk per APUBUG-PRODUCER-001)
## Discipline
xenia-rs HEAD `25704c5` unchanged. No source modifications. No canary patch applied (skipped per task — static picture was sufficient). `git status --short` showed only pre-existing untracked `audit-runs/*` + `M audit-findings.md` (predates audit-049).
Trace at `audit-runs/audit-049-tid1-stall-0x1280/{ours-trace.log, signaler-analysis.csv, findings.md}`.
## Recommended user-decision
Path 2 (audio-host-pump) made trajectory progress (1 layer deeper into boot) but didn't cross the renderer plateau. The 5-consecutive-converge signal indicates **path 1 (Wine/Lutris canary)** is now justified per the user's prior framing: "save path 1 for after it, when we did not make any meaningful progress."
"Meaningful" is the judgement call:
- Trajectory: YES (4 wedges unblocked, 16 new exports, +1 layer)
- Plateau: NO (swaps ≤ 2, draws = 0, same cluster blocks)
Hand back to user.

63
migration/claude-memory/project_xenia_rs_audit_050_reframe_2026_05_10.md Normal file
View File

@@ -0,0 +1,63 @@
---
name: AUDIT-050 GENERAL-AUDIT + REVISIT — methodological reframe (2026-05-10)
description: 11 prior audits' "audit-009 cluster unreachable" claim is a STATIC-ANALYZER ARTIFACT, not a runtime fact. Runtime probing via --ctor-probe shows the cluster IS reached: CRT static-init driver sub_824ACB38 (called from entry_point directly) iterates 14 fnptr arrays at 0x82870xxx including 24 GamePart factory regs; tid=13's full chain fires (sub_821C4EB0/sub_821CC3F8/sub_821CBA08/sub_821CB030); work-submitter sub_82452DC0 fires on tid=13 at cycle 8127. Real bug is γ-class missing-signaler INSIDE sub_82452DC0's descendant tree. Angle B (long-horizon 5B) DEFINITIVELY FALSIFIED — bit-identical counters at 500M and 5B. 14th reading-error class added.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🔍 AUDIT-050 META-FINDING (2026-05-10, READ-ONLY, master `25704c5` unchanged)** — two parallel subagents (general-audit + revisit-injection) produced a methodological reframe that invalidates the central premise of audits 044-049.
## The reframe
**11 prior audits (009/016/017/020/021/026/027/029/031/032/033/034/035/044/045/046/047/049) claimed "audit-009 cluster unreachable" based on static `bl` BFS + M5.5 typed-vptr indirect BFS.** Direct runtime probing via `--ctor-probe` falsifies this:
- CRT static-init driver `sub_824ACB38` (statically reachable from `entry_point=0x824ab748`) iterates `0x82870010..0x828708C4` = **557 fnptr slots** with 82 non-NULL fnptrs at boot, including 24 GamePart factory registrations.
- `sub_8280E148` = `RegisterToFactory<0,silph::GamePart_Title>` **fires at cycle 1,396,320**.
- ALL 4 of audit-049's "unreachable" tid=13 chain functions (`sub_821C4EB0`, `sub_821CC3F8`, `sub_821CBA08`, `sub_821CB030`) **DO fire on tid=13** at cycles 1882-3242.
- Work-submitter `sub_82452DC0` **fires on tid=13** at cycle 8127 from `lr=0x821cb1d0` (= `sub_821CB030+0x19C`, the call site audit-049 named).
**The cluster IS reached at runtime. The actual bug is γ-class missing-signaler INSIDE sub_82452DC0's descendant tree** — work submission completes but the callback path that would `NtSetEvent(0x1288)` and unpark tid=13 doesn't fire.
## 14th reading-error class
**BFS-only reachability claims are insufficient when the binary uses CRT-driven function-pointer arrays.** The CRT static-init driver invokes fnptrs via `bcctrl` from data-resident arrays at module-load time; static `bl` BFS doesn't traverse these. Mitigation: verify with `--ctor-probe` runtime probing BEFORE claiming a function is unreached.
## Angle B (long-horizon 5B) — DEFINITIVELY FALSIFIED
The general-audit ran -n 5,000,000,000 in background. **Bit-identical kernel counters** to 500M baseline (NtCreateEvent 104=104, NtSetEvent 68=68, NtWaitForSingleObjectEx 30=30, VdSwap 1=1, all 90+ counters identical). Wall time 234s vs ~12s. System reaches deterministic stall and does literally nothing more. Saved at `audit-runs/audit-050-general-audit/extended-5B.err`.
## Revisit agent: cluster injection feasibility
Dedicated-worker pattern from AUDIT-048 IS mechanically reusable but cluster injection is **HIGH-risk crash-likely** for chain roots. The two LOW-risk targets only write ONE vptr each — single-ctor injection cannot bootstrap a multi-ctor chain. Recommend AGAINST cluster injection as a fix; only viable as ~60 LOC diagnostic probe.
**Critical sub-finding**: cluster is **HALF-bootstrapped** — tid=13 (worker-thread subset) runs, but vtables (writer subset) are never written, so virtual dispatches in the running chain hit garbage. Reframes "entire cluster dead" → "vtable-writer subset specifically dead but worker-thread subset live."
## Combined hypothesis
The two subagents converge: **somewhere in `sub_82452DC0`'s descendant tree there is a virtual dispatch (or function-pointer call) that goes to a wrong/null vtable slot** because the vtable writer for that slot didn't fire. The right callback (which would NtSetEvent(0x1288)) is at a vtable slot that wasn't populated.
## Top recommended angle: Angle I — work-submitter trace
Probe `sub_82452DC0`'s 9 direct call targets + its 1 ind_call site in BOTH engines:
```
0x82452DC0 -- entry
0x8245AE50, 0x82452068, 0x82452200, 0x8245B000, 0x8245B078,
0x82454A40, 0x82452AB8, 0x82454918, 0x82452EC4
```
Find the divergent branch. Sharp 4-dim cascade prediction:
- A: signal_attempts on 0x1288 0→≥1
- B: tid=13 Blocked→Ready→Exit, unparking tid=1's join
- C: NtSetEvent count delta 68→≥69
- **D: swaps>2 OR draws>0: YES POSSIBLE** (30-50% confidence, highest since AUDIT-032)
Wine canary is **no longer the only credible route**. Angle I has genuine EV given today's reframe.
## Strategic position
Sessions 1-2 of this 7-budget: General-audit + Revisit (PARALLEL, completed).
Sessions 3-7 remaining: drive Angle I to root cause + bounded fix.
Trace artifacts at:
- `audit-runs/audit-050-general-audit/{extended-5B.err, extended-5B.log, angle-comparison.csv, db-evidence.txt}`
xenia-rs HEAD `25704c5` unchanged. swaps=2 draws=0 plateau intact (post re-baseline).

63
migration/claude-memory/project_xenia_rs_audit_051_work_submitter_trace_2026_05_10.md Normal file
View File

@@ -0,0 +1,63 @@
---
name: AUDIT-051 work-submitter divergence at sub_8245B078 (2026-05-10)
description: Concrete divergence found inside sub_82452DC0's descendant tree. sub_8245B078 fires 18× canary / 0× ours — CANARY-ONLY. Gate at sub_82452DC0+0x78 (PC 0x82452E2C `beq cr6, 0x82452E88`) controlled by sub_8245B000 which returns 1 iff [r3+0]≠0 AND [r3+4]≠0 for an 80-byte struct at r31+96. Ours has one of those fields NULL — missing-population data divergence. Struct upstream-written by sub_8245AE50/sub_82452068/sub_82452200 (all fire in both, same shape, just ours doesn't write the right fields). Gate-failure explains AUDIT-047's 4 wedges (0x10A0/0x10A4/0x1530/0x1534) via sub_8245AD00 + plausibly tid=13's stall on 0x1288. Cascade D=draws>0 LOW-MEDIUM 20-30% (5 vtable dispatches downstream might re-hit unreachability island).
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-051 (2026-05-10, READ-ONLY, master `25704c5` unchanged, canary `6de80dffe` clean)**: Angle I work-submitter trace per AUDIT-050 reframe. 10 PCs probed in canary + ours.
## Comparison table
| PC | Canary | Ours | Class |
|---|---|---|---|
| 0x82452DC0 (entry) | 45 | 8 | CANARY-OVER 5.62× |
| 0x8245AE50 | 84 | 19 | CANARY-OVER 4.42× |
| 0x82452068 | 77 | 17 | CANARY-OVER 4.53× |
| 0x82452200 | 72 | 17 | CANARY-OVER 4.24× |
| 0x8245B000 | 45 | 8 | CANARY-OVER 5.62× |
| **0x8245B078** | **18** | **0** | **CANARY-ONLY (THE BUG)** |
| 0x82452AB8 | canary-crash | 9 | INCONCLUSIVE |
| 0x82454A40 | canary-crash | 2445 | INCONCLUSIVE; OURS-OVER (heavy util) |
| 0x82454918 | canary-core | 152 | INCONCLUSIVE |
| 0x82452EC4 | canary-core | 0 | INCONCLUSIVE; mid-block ind-call (RE class #13) |
Same-shape ratio ~4.2-5.6× for all reaching PCs is the audit-009 cluster signature (tid=13 runs but fewer iters/sec because cluster is half-bootstrapped per AUDIT-050 reframe).
## The bug
PC `0x82452E2C` is `beq cr6, 0x82452E88` immediately after `bl sub_8245B000` (at `0x82452E1C`). `sub_8245B000` is a tiny gate that returns:
```
return [r3+0] != 0 AND [r3+4] != 0
```
for an 80-byte stack-local struct at `r31+96` of `sub_82452DC0`. **In ours, at least one of those two pointers is NULL → predicate fails → branch skips `sub_8245B078`. In canary, both non-zero → predicate passes → 18 fires.**
The struct is populated upstream by callees `sub_8245AE50` / `sub_82452068` / `sub_82452200`. All three fire in BOTH engines (same shape ratio), but ours writes incomplete data into the struct.
## Connection to AUDIT-047
`sub_8245B000`'s "true" path also calls **`sub_8245AD00`** — which AUDIT-047 already identified as the signal source for 4 of the NO_SIGNALS_DESPITE_WAITS wedge handles: `0x10A0`, `0x10A4`, `0x1530`, `0x1534`. **Single root cause** for those 4 wedges: the work-submitter's local struct is malformed, gating off the signal-payload chain.
Likely also explains tid=13's stall on event 0x1288 (audit-049) since `sub_8245AD00` may signal `0x1288` too via the same path.
## Why divergence is direct-bl, not vtable
`sub_82452DC0` does contain 5 indirect-dispatch sites (`pc=0x82452EC4` slot=5 cands=85; `0x82452EF0` slot=2 cands=203; `0x82452F30`/`0x82452FC4`/`0x82453014` slot=5 cands=85). But ALL of them sit AFTER the divergence at +0x78. The bug stops execution before reaching the vtable dispatches — so M5.5 vtable analysis isn't on the critical edge here. **Refines the AUDIT-050 "vtable-writer-island deadness" framing**: at the work-submitter level, the bug is data population (a stack-local struct), not vtable. The vtable issue MAY re-bite downstream of the gate-fix; that's why cascade D is only 20-30%.
## Recommended AUDIT-052
Dump the 80-byte struct at `r31+96` of `sub_82452DC0` at PC `0x82452E1C` (just before `bl sub_8245B000`) in BOTH engines. Compare first 16 bytes canary vs ours; identify which of `[+0]`/`[+4]` is NULL in ours. Then probe `sub_8245AE50`/`sub_82452068`/`sub_82452200` to find the missing writer.
Single PC, single dump in each engine. ~10 min wallclock.
## Sharp 4-dim cascade prediction (post AUDIT-052/053 fix)
- **A**: `sub_8245B078` fires in ours 0→≥1 — HIGH confidence (direct gate flip)
- **B**: tid=13 Blocked→Ready — MEDIUM (depends on whether `sub_8245AD00`'s tail signals `0x1288`)
- **C**: NO_SIGNALS_DESPITE_WAITS drops ≥2-4 (AUDIT-047's 4 wedges) — MEDIUM-HIGH
- **D**: `swaps>2 OR draws>0` — **20-30% LOW-MEDIUM**. The 5 ind_call sites in `sub_82452DC0+0x104..+0x254` (vtable[5]/[2] cands=85/203) sit downstream; if path enters them, vtable-writer-island deadness re-bites. AUDIT-052/053 fix is necessary but likely not sufficient.
This is the **first concrete divergence to attack** since AUDIT-032's audio fix.
## Discipline
xenia-rs HEAD `25704c5` unchanged. xenia-canary HEAD `6de80dffe` clean (audit-030 patch reverted, `git status --short` empty for tracked). Trace `audit-runs/audit-051-work-submitter-trace/{canary-0x*.log×10, ours-multi-probe.log, findings.md, canary-patch.diff}`.

70
migration/claude-memory/project_xenia_rs_audit_052_cache_root_cause_2026_05_10.md Normal file
View File

@@ -0,0 +1,70 @@
---
name: AUDIT-052 — root cause cache-wipe-on-boot 2026-05-10
description: AUDIT-051's struct hypothesis REFUTED — struct at sub_82452DC0:r31+96 is bit-identical canary vs ours. The two dwords [r3+0]/[r3+4] are halves of a hash key formatted into `cache:\<HASH1>\<X>\<HASH2>` paths. Real bug — `NtQueryFullAttributesFile` returns -1 for cache:\* in ours because AUDIT-038's per-boot tmpdir cache is WIPED on every startup; canary's persistent cache at `~/.local/share/Xenia/cache/` has pre-built files. **Reading-error class #15**: AUDIT-038's "missing-or-stale ≡ fresh" assumption invalidated. Fix = persistent cache. Cascade A/B/C HIGH confidence; D 30-40%.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-052 (2026-05-10, READ-ONLY, master `25704c5` unchanged, canary clean)**: dumped 80-byte struct at `r31+96` of `sub_82452DC0` at PC `0x82452E1C` in both engines.
## Hypothesis REFUTED — struct is bit-identical
AUDIT-051 hypothesized ours had NULL in `[r3+0]` or `[r3+4]`. Both are NON-ZERO in all 8 ours fires (e.g. `d0=d4ea4615 d1=e46ee8ca`), matching canary fire 0 byte-for-byte modulo stack base address. Probing at `0x8245B020` confirms predicate 1 passes 8/8 in ours. **The struct is fine. The writers do their job. AUDIT-051's writer-triage is moot.**
## What the struct contains
`[r3+0]` and `[r3+4]` are **two halves of a hash key** that gets formatted into a `cache:\<HASH1>\<X>\<HASH2>` filesystem path by `sub_82459130`:
```
ours fire 0 path bytes (BE-decoded): "cache:\d4ea4615\e\46ee8ca\0"
^^^^^^^^ ^^^^^^^
= d0 = d1 high bits
```
Canary's log shows `RtlInitAnsiString(...,cache:\d4ea4615\e\46ee8ca)` followed by `NtQueryFullAttributesFile(...)` for the same path.
## Real root cause: NtQueryFullAttributesFile fails in ours
PC-probes inside `sub_8245AD00`:
- ours probe at PC `0x8245AD94` (success path post-NtQuery): **0 fires**
- ours probe at PC `0x8245ADFC` (failure path): **8 fires**
`NtQueryFullAttributesFile` returns -1 for **every cache lookup** in ours. This propagates: `sub_8245AD00` returns 0 → `sub_8245B000` returns 0 → gate `bne` at `0x82452E2C` skips → `sub_8245B078` never called.
## AUDIT-038 cache-clear-on-boot at fault
`crates/xenia-kernel/src/state.rs:387-398` (`init_cache_root`): creates a per-process tmpdir cache and **wipes it on every emulator startup** (`remove_dir_all` then `create_dir_all`).
Canary's host cache at `~/.local/share/Xenia/cache/` is **persistent and pre-populated** with runtime-built game files:
```
/home/fabi/.local/share/Xenia/cache/d4ea4615/e/46ee8ca
/home/fabi/.local/share/Xenia/cache/69d8e45c/...
/home/fabi/.local/share/Xenia/cache/87719002/...
/home/fabi/.local/share/Xenia/cache/aab216c3/...
```
These are likely shader/PSO/material caches Sylpheed builds during gameplay and persists. Ours starts fresh every time, so all `cache:\*` lookups return `STATUS_OBJECT_NAME_NOT_FOUND`.
## Reading-error class #15
AUDIT-038's framing: "per-boot tmpdir cache is deterministic and safe because Sylpheed treats missing-or-stale identically to fresh." **REFUTED** — the work-submitter wakeup path is GATED on cache existence; without populated cache, no fall-through that does the work. Class: **opportunistic-cache assumption violation**.
## Sharp 4-dim cascade prediction (post AUDIT-053 fix)
Make cache root persistent (and either pre-populate or accept that first-boot won't cross plateau):
- **A**: `0x82452E30` fires > 0 in ours (gate passes) — **HIGH** confidence
- **B**: `sub_8245B078` fires > 0 — **HIGH**
- **C**: AUDIT-047's 4 wedges (`0x10A0/0x10A4/0x1530/0x1534`) get NtSetEvent — **HIGH**
- **D**: `swaps>2 OR draws>0` — **30-40%** (cache may not be only gate; tid=1 on 0x1280 may persist; downstream might need file CONTENTS not just existence)
## Recommended AUDIT-053 (cheapest test)
1. Symlink ours's cache root → canary's `~/.local/share/Xenia/cache/` (or copy contents) BEFORE `init_cache_root` wipes; OR temporarily comment out `remove_dir_all`
2. Re-run with `--pc-probe=0x82452E30,0x8245B078` and see if gate passes
If gate passes with canary's pre-populated cache → existence is sufficient OR contents are sufficient (canary's). Either way, fix = persistent cache + (maybe) pre-population strategy.
If gate still fails → contents matter MORE than canary's cache provides → bigger problem.
## Discipline
xenia-rs HEAD `25704c5` unchanged. xenia-canary HEAD `6de80dffe` clean. All probe extensions reverted via `git checkout`. Trace at `audit-runs/audit-052-struct-dump/{disasm.txt, canary-traces.txt, ours-third-pred.log, canary-0x82452E24.log, ...}`. Largest log ~135MB (canary trap).

81
migration/claude-memory/project_xenia_rs_audit_053_cache_layout_bug_2026_05_10.md Normal file
View File

@@ -0,0 +1,81 @@
---
name: AUDIT-053 — cache layout aliasing bug found 2026-05-10
description: Phase 1 (canary cache override) PASSES cascade A/B — gate at sub_82452DC0+0x78 flips on existence of cache:\<HASH1>\<X>\<HASH2>. BUT cascade C/D FAIL — NtSetEvent dropped 68→63, VdSwap=1 unchanged, draws=0. Phase 2-4 (permanent persistent-cache fix) REVERTED due to deeper layout bug: open_cache_file treats all NtCreateFile as files, but Sylpheed wants cache:\d4ea4615 as a DIRECTORY. 0-byte file d4ea4615 blocks subsequent hierarchical creates on warm-start. 15th reading-error class — VFS layout aliasing (ζ-class). Next: AUDIT-054 fix open_cache_file to honor FILE_DIRECTORY_FILE bit.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-053 (2026-05-10, READ-ONLY at end, master `25704c5` unchanged, source mods reverted)**: persistent-cache experiment + permanent fix attempt. Phase 1 confirmed AUDIT-052's gate hypothesis. Phase 2-4 reverted due to deeper bug.
## Phase 1: hypothesis test (canary-cache override)
Override `XENIA_CACHE_ROOT="$HOME/.local/share/Xenia/cache"` (canary's pre-populated cache directory).
| PC | Pre-fix | Post-fix | Verdict |
|---|---|---|---|
| `0x82452E30` (gate) | 0 | **6** | PASS |
| `0x8245B078` (callback) | 0 | **6** | PASS |
| `0x8245AD94` (cache-found) | 0 | **6** | PASS |
| `0x8245ADFC` (cache-miss) | many | **2** | PASS |
**Cascade A/B: PASS.** Cache existence IS the gate.
## Phase 1b: Stats vs master `25704c5` baseline
| Metric | Baseline | Override | Δ |
|---|---|---|---|
| `VdSwap` | 1 | 1 | 0 |
| `gpu.interrupt.delivered{src=0}` | 54 | 52 | -2 |
| `NtSetEvent` | 68 | **63** | **-5** |
| `NO_SIGNALS_DESPITE_WAITS` count | 6 | 6 | 0 (different wedges) |
**Cascade C: FAIL** (NtSetEvent went DOWN, not UP). **Cascade D: FAIL** (VdSwap=1, draws=0 unchanged). Gate passes into callback chain but downstream signaling does NOT happen as predicted.
## Phase 2-4: permanent fix REVERTED
Implemented `init_cache_root_ext(root, wipe)` + env-var selector — ~50 LOC. Cold-start identical to baseline (cache empty). **Warm-start REGRESSION**:
| Metric | Cold | Warm |
|---|---|---|
| VdSwap | 1 | **0** |
| NtSetEvent | 68 | **2** |
| ExCreateThread | 10 | **3** |
| NtCreateEvent | 101 | **8** |
**Root cause**: `crates/xenia-kernel/src/exports.rs:open_cache_file` treats ALL `NtCreateFile` as files. Sylpheed issues two overlapping path kinds:
1. `NtCreateFile cache:\<HASH1><HASH2>.tmp disp=OVERWRITE_IF` → flat filename, file
2. `NtCreateFile cache:\<HASH1> disp=CREATE` → meant as a DIRECTORY container
We create both as files. On warm-start, the 0-byte file `d4ea4615` blocks subsequent hierarchical creates of `cache:\d4ea4615\e\46ee8ca`. Canary correctly stores it as `d4ea4615/e/46ee8ca` directory tree.
AUDIT-038's wipe-every-boot **masked this for 14 audits**.
## Reading-error class #15 (NEW)
**ζ — VFS layout aliasing**. NtCreateFile path semantics: caller-specified `FILE_DIRECTORY_FILE` bit in `CreateOptions` (or path-pattern heuristic) determines whether the create is a file or directory. Treating all as files works only when the cache is wiped before each boot — which is exactly what AUDIT-038 did, masking the bug.
Distinct from γ (missing-signaler), δ (handle namespace), ε (heap addr), η (record layout). This is host-FS modeling.
## Recommended AUDIT-054 (Two-track, priority order)
### Track A (high-confidence, ≤30 LOC) — fix VFS layout
`crates/xenia-kernel/src/exports.rs:open_cache_file`. Honor `FILE_DIRECTORY_FILE` bit in CreateOptions when set. Quick verification: dump CreateOptions in existing log + grep for bit on the colliding `cache:\d4ea4615 disp=2` request.
Fallback heuristic: if `disp=FILE_CREATE` AND path has NO extension AND a sibling `<path><suffix>` exists → directory.
After Track A lands, re-apply Track B (persistent cache from this audit's reverted patch). If layout fix correct → warm-start no longer regresses → cache:\<H1>\<X>\<H2> succeeds → cascade C may rise.
### Track B (if Track A doesn't unstick cascade D)
Trace inside `sub_8245B078` with `--branch-probe` to find divergent branch on the now-reachable callback path. Sub-PCs to probe: every basic block within sub_8245B078 (need to enumerate via DB + disasm).
## Sharp 4-dim cascade prediction (post Track A + Track B persistent cache)
- A: gate passes (already confirmed in Phase 1) — HIGH
- B: sub_8245B078 fires + downstream callbacks runs — HIGH
- C: NtSetEvent rises ≥4 (AUDIT-047's wedges) — MEDIUM-HIGH (depends on Track A success)
- **D: swaps>2 OR draws>0** — STILL 30-40% per AUDIT-052 (cache may not be only gate)
## Discipline
xenia-rs HEAD `25704c5` unchanged at session end. All source mods reverted via `git checkout`. `git status crates/`: nothing to commit. cargo test 127/127 pass. Canary unmodified this session. Trace at `audit-runs/audit-053-persistent-cache/{phase1-experiment.log, phase1-canary-trace.log, baseline-master-500m.log, baseline-tmpfs-500m.log, validation-coldstart-500m.log, validation-warmstart-500m.log}`.

72
migration/claude-memory/project_xenia_rs_audit_054_vfs_layout_landed_2026_05_10.md Normal file
View File

@@ -0,0 +1,72 @@
---
name: AUDIT-054 — VFS layout fix (Track A) LANDED 2026-05-10
description: Track A (FILE_DIRECTORY_FILE bit handling in nt_create_file/open_cache_file) committed `2a8ff95`. Golden re-baselined `ac2f89a`. Track B (persistent cache) implemented as OPT-IN via XENIA_CACHE_PERSIST=1; default remains AUDIT-038 wipe-on-boot to preserve lockstep. Track A correctness fix: cache:\<HASH> opens with disp=2 opts=0x4021 → mkdir; subsequent leaf cache:\<HASH>\<X>\<HASH> with opts=0x4020 → file. Cascade A confirmed (hierarchy correctly created on disk with PERSIST). Cascade C/D NO MOVEMENT — confirms AUDIT-053 finding that cache is necessary but not sufficient. Persistent warm-start regresses (cxx_throw=10) due to our cold-start halting at swaps=1 producing half-baked .tmp journals.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-054 (2026-05-10, IMPLEMENTATION LANDED)**: master HEAD advanced `25704c5 → 2a8ff95 → ac2f89a` (2 commits). Closes ζ-class VFS layout aliasing for `cache:\*` paths.
## Commits
- `2a8ff95` AUDIT-054: thread CreateOptions through NtCreateFile + opt-in cache persistence (74 net code LOC ≤ 80 budget)
- `ac2f89a` Re-baseline sylpheed_n50m golden post-AUDIT-054 (1-instruction drift `50000002 → 50000001`; all other digest fields bit-identical)
## Track A — FILE_DIRECTORY_FILE handling
`crates/xenia-kernel/src/exports.rs` +50 / -5. `nt_create_file` reads `create_options` from `sp + 0x54` (9th-arg slot per canary `xenia/kernel/util/shim_utils.h:49-50`); `nt_open_file` forwards `open_options` from `r8`. `open_vfs_file`/`open_cache_file` thread the options through. When `FILE_DIRECTORY_FILE` (bit 0x1) is set on a `cache:\*` path, runs `std::fs::create_dir_all` instead of `File::create`. Stored handle's `path` ends with `/` so `nt_query_information_file` reports Directory=1.
Discriminator on disk:
- `cache:\d4ea4615` opens with `disp=2 opts=0x4021` (FILE_CREATE+FILE_DIRECTORY_FILE) → mkdir ✓
- `cache:\d4ea4615\e` opens same way → mkdir ✓
- `cache:\d4ea4615\e\46ee8ca` opens with `opts=0x4020` (no DIR bit) → file ✓
- `cache:\d4ea4615e46ee8ca.tmp` (flat) opens with `opts=0x4020` → file ✓
The 0-byte sentinel that masked AUDIT-038's wipe behavior for 14 audits is gone.
## Track B — opt-in persistent cache
`crates/xenia-kernel/src/state.rs` +90 / -9. New `resolve_default_cache_root()` returns `(PathBuf, wipe: bool)`. Defaults preserved (AUDIT-038 wipe-on-boot for lockstep). Persistence opt-in:
- `XENIA_CACHE_ROOT=<path>` — explicit user override, no wipe
- `XENIA_CACHE_PERSIST=1` — `$XDG_DATA_HOME/xenia-rs/cache` or `$HOME/.local/share/xenia-rs/cache`, no wipe
- New helper `KernelState::set_cache_root(path)` for tests/oracle setups
## Cold/warm-start observations
| Mode | Boot | swaps | draws | cxx_throw | Notes |
|---|---|---|---|---|---|
| default (wipe) | cold | 1 | 0 | 0 | bit-identical to master baseline |
| `XENIA_CACHE_PERSIST=1` | cold | 1 | 0 | 0 | same digest + correct hierarchy on disk |
| `XENIA_CACHE_PERSIST=1` | warm | **0** | 0 | **10** | REGRESSION — Sylpheed appends to existing .tmp; version header stale; throws `runtime_error 0xe06d7363` |
| `XENIA_CACHE_ROOT=$HOME/.local/share/Xenia/cache` | warm | 1 | 0 | ? | (per AUDIT-053 Phase 1: gate passes, sub_8245B078 fires 6×, NtSetEvent 68→63, no D progress) |
The warm-start cxx_throw is a SECONDARY problem caused by our cold-start halting at swaps=1 producing half-baked .tmp journal files. Sylpheed's pattern: cold boot writes 400 bytes to `cache:\<HASH>.tmp`; warm boot seeks to end-of-file, appends another 400 bytes; reads version header from `cache:/access` which is now stale. Real fix would be: let cold boot complete the cache cycle before quitting (or implement journal-truncate-on-mismatch, or compute the version header correctly).
## Cascade A/B/C/D verdict
- **Cascade A** (gate flips on cache existence): CONFIRMED in AUDIT-053 Phase 1; CORRECTED for layout via Track A
- **Cascade B** (sub_8245B078 fires): CONFIRMED in AUDIT-053 Phase 1 (6 fires with canary cache override)
- **Cascade C** (NtSetEvent rises): FAIL — went 68→63 with canary cache; downstream signaling does not happen
- **Cascade D** (swaps>2 OR draws>0): FAIL — VdSwap=1 unchanged
**The cache fix is necessary but not sufficient.** Next gate is INSIDE `sub_8245B078`'s body or one of its callees.
## Recommended AUDIT-055 (final session of 7-budget run)
Probe `sub_8245B078`'s body in BOTH engines with `XENIA_CACHE_ROOT` set to canary's pre-populated cache (so the gate passes in ours and sub_8245B078 fires). Compare:
- Inner basic-block fire counts via `--pc-probe` (or `--branch-probe` if available)
- Identify the divergent branch
- Trace LR chain at divergence
`sub_8245B078`'s callees per AUDIT-051: `sub_82459130, sub_8217FA08, sub_82454498, sub_82454580, sub_825F3C48`. Probe their entries.
Sharp 4-dim cascade prediction (post AUDIT-055 + bounded fix):
- A: divergent branch correctly taken in ours — HIGH
- B: downstream callees fire — MEDIUM
- C: NtSetEvent rises — MEDIUM
- D: draws>0 — STILL 20-40% (per AUDIT-052 prediction; may need MULTIPLE wedge fixes)
## Discipline
xenia-rs HEAD `ac2f89a`. Tests: kernel 127/127, app 5/5 + sylpheed_n50m oracle pass. Goldens re-baselined cleanly. No hooks skipped. Commits authored cleanly with Co-Authored-By trailer.
Trace `audit-runs/audit-054-vfs-layout-fix/{cold-start-500m.log, warm-start-500m.log, persist-cold-500m.log, persist-warm-500m.log, baseline-master-500m.log}`.

50
migration/claude-memory/project_xenia_rs_audit_055_subB078_internal_2026_05_10.md Normal file
View File

@@ -0,0 +1,50 @@
---
name: AUDIT-055 — sub_8245B078 internal probe (final autonomous session) 2026-05-10
description: Probed sub_8245B078's body in both engines with XENIA_CACHE_ROOT=canary. Body executes correctly — internal calls have ~98% parity (sub_8217FA08 2449/2411). Divergence is UPSTREAM: sub_82452DC0 fires 5.6× less in ours per AUDIT-051. Sharpest specific divergence: sub_8217FA08 from LR=0x82455E60 (=sub_82455DF0+0x70), canary 20 fires / ours 0. Bug class refined to δ-throughput: producer of work items doesn't fire at canary rate. Recommended AUDIT-056: probe sub_82452DC0 entry, aggregate LR distribution, identify divergent caller; recurse upward.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-055 (2026-05-10, READ-ONLY, master `ac2f89a` unchanged, canary clean post-revert)**: FINAL session of 7-session autonomous run. Probed `sub_8245B078`'s body with `XENIA_CACHE_ROOT=/home/fabi/.local/share/Xenia/cache` override on ours (so gate passes and sub_8245B078 fires).
## Comparison table (6 PCs)
| PC | Function | Canary | Ours | Ratio | Class |
|---|---|---|---|---|---|
| 0x8245B078 | entry | 19 | 6 | 3.2× | uniform shortfall |
| 0x82459130 | string-format | 44 | 13 | 3.4× | uniform shortfall |
| 0x8217FA08 | string-set+register | 2449 | 2411 | **1.02×** | parity |
| 0x82454498 | registry lazy-init | 3840 | 2771 | 1.39× | mixed |
| 0x82454580 | registry insert | 3101 | 2587 | 1.20× | mixed |
| 0x825F3C48 | stack-cookie check | 6743 | 5334 | 1.26× | broad |
Plus arm-entries: `0x8245B0CC` (THEN) ours=6, `0x8245B0EC` (ELSE) ours=0. **sub_8245B078 always takes THEN in both engines.**
## Verdict
`sub_8245B078`'s BODY executes correctly. Internal call parity confirms cluster behavior is correct **once entered**. The remaining 3.2× shortfall is **upstream** — fewer parents activate the cluster's worker paths.
Sharpest specific divergence: `sub_8217FA08` called from `LR=0x82455E60` (= `sub_82455DF0+0x70`). Canary 20 fires / Ours 0 fires (CANARY-ONLY at this call-site). `sub_82455DF0` is a path-walking helper with 332+ static callers spread across renderers `0x822A*-0x823C*`, audio, kernel-shim. Missing fires suggest missing resource-name-resolution pathway in sister code path.
## Combined hypothesis (audits 051+053+055)
Chain: `producer → sub_82452DC0 → sub_8245B000 (cache check) → sub_8245B078 → sub_8217FA08`. AUDIT-054's cache fix closed the gate at sub_8245B000 (cascade A/B). The remaining 3-4× shortfall is upstream of sub_82452DC0 — the **producer of work items** isn't firing at canary's rate.
Bug class refined to **δ-throughput** (signal/work generator firing less than canary; not content/correctness divergence at this layer).
## Recommended AUDIT-056 (post-7-budget, user-triggered)
**Work-submitter parent identification**. Probe `sub_82452DC0` entry in BOTH engines; aggregate LR distribution; identify top divergent caller. Recurse upward 2-3 levels until divergence dilutes. Per audit-051 we know LR=0x82448120 is dominant in ours; canary's distribution at sub_82452DC0 entry not yet aggregated. Effort: 30 min wallclock, ≤4 PC probes.
Sharp 4-dim cascade prediction (if AUDIT-056 identifies and fixes the divergent producer):
- A: sub_82452DC0 fires ours 8 → ≥30 (close half the gap)
- B: sub_8245B078 fires ours 6 → ≥15
- C: sub_82455DF0 fires ours 0 → ≥5
- **D: draws>0** 20-30% (cluster fed at parity may advance state machine; Linux Vulkan/XCB still blocks intro display). **swaps>2** 40-50% (audio + cluster + cache could combine to advance past splash).
Alternative if AUDIT-056 finds producer is in audit-009 island: **AUDIT-057 = M5.5 alias-aware static dispatch resolution** to enumerate vtable entry paths into the cluster, then targeted probe/inject.
## Discipline
xenia-rs HEAD `ac2f89a` unchanged. Canary HEAD `6de80dffe` clean post-revert. No source mods this session, no commits. Trace `audit-runs/audit-055-sub_8245B078-internal/{canary-0x*.log, ours-multi-probe.log, canary-0x8245B078-redo.log}` ~15 MB.
Note: during canary build, lost ~10 min recovering from hardware-induced cache corruption (`executable_addr_flags.bin` truncated to 0 bytes by SATA bus-error per `dmesg`); deleted to allow canary rebuild. Documented for recurrence.

58
migration/claude-memory/project_xenia_rs_audit_056_producer_trace_2026_05_10.md Normal file
View File

@@ -0,0 +1,58 @@
---
name: AUDIT-056 — sub_82452DC0 producer trace 2026-05-10
description: Aggregated LR distribution at sub_82452DC0 entry in canary (45 fires/60s) vs ours (14 fires/26s). Two distinct CANARY-ONLY divergence introducers: (a) sub_821C4EB0 calls sub_821CEDF8 5× in canary, 0× in ours — internal cascade missing despite identical entry conditions; (b) sub_824AFF88 thread-trampoline fires 5× in canary, 0× in ours (12 vs 30 XThread count gap). The 3.21× sub_82452DC0 throughput ratio matches the 3.0× thread-count ratio. Reading-error #13 limits internal probing inside sub_821C4EB0; need --lr-trace granularity extension.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-056 (2026-05-10, READ-ONLY, master `ac2f89a` unchanged, canary clean post-revert)**: producer-trace per AUDIT-055 recommendation.
## LR distribution at sub_82452DC0
| LR | Canary | Ours | Resolved fn |
|---|---|---|---|
| `0x82452E64` | 19 | 6 | sub_82452DC0+0xA4 (self-recursion) |
| `0x82460CC8` | 7 | 2 | sub_82460B70+0x158 (0 static callers — vtable entry) |
| `0x821CBF7C` | **7** | **0** | sub_821CBEA8+0xD4 |
| `0x821C4C98` | **5** | **0** | sub_821C4AE0+0x1B8 (0 static callers — vtable entry) |
| `0x82448120` | 4 | 4 | sub_824480D0+0x50 (parity) |
| `0x821790B8` | 0 | 1 | sub_82178F60+0x158 |
| `0x821CB1D0` | 0 | 1 | sub_821CB030+0x1A0 (audit-049 chain) |
Total: canary 45 fires / ours 14 = **3.21×** ratio.
## Two divergence introducers
### (a) sub_821C4EB0 internal cascade
- Level 3 entry (sub_821C4EB0): canary 1 / ours 1 with **identical caller LR=0x82174A80** = sub_82174828+0x258. **PARITY at entry.**
- sub_821C4EB0 contains 5 unconditional `bl 0x821CEDF8` calls at offsets +0x198, +0x1C4, +0x1F0, +0x218, +0x240
- Canary takes ALL 5; ours takes 0
- **Ours's sub_821C4EB0 returns early before +0x198** — static disasm shows early-exit candidates at +0x44/+0x48 (r3==0 from sub_82150EF8), +0x88/+0x8C (state-byte gate), +0xBC/+0xC0 (r3==0 from sub_82172370), +0xD8..+0xE0 (jump-table on r11)
- Reading-error #13 prevents direct internal-PC verification in ours (`--pc-probe` block-entry-only)
### (b) sub_824AFF88 thread trampoline
- Ends with `bl __imp_xboxkrnl.ExTerminateThread` — thread entry trampoline
- Canary fires 5× (lr=0xBCBCBCBC, fresh-stack pattern); ours 0×
- Ground truth: **canary 30 XThreads (tids 1..0x1E), ours 12 XThreads — 18 missing threads**
- 3.0× thread-count ratio matches the 3.21× sub_82452DC0 throughput ratio
## Recommended AUDIT-057
**Probe sub_82174828 entry** (caller of sub_821C4EB0 at LR=0x82174A80) + `--lr-trace` at the post-bl basic-block-entry PCs inside sub_821C4EB0: `0x821C4F2C, 0x821C5014, 0x821C5048`. Block-entry-only granularity will at least tell us where ours's path forks.
If granularity insufficient (reading-error #13 reconfirmed), extend `--lr-trace` to per-instruction granularity matching canary's `--log_lr_on_pc`.
Sharp 4-dim cascade prediction (post AUDIT-057 fix on early-return predicate):
- A: sub_82452DC0 fires 14 → 25+ in ours
- B: thread count rises 12 → 18+
- C: sub_821CBEA8 fires 0 → ≥3
- D: draws>0 — **20-30%** (worker-thread subset live but vtable-writer subset dead per AUDIT-050 — fixing one early-return may not bridge that)
**Fallback** if no clean predicate: pivot to direct audit of which 18 ExCreateThread/NtCreateThread calls fail to land. Compare canary 30 vs ours 12 thread-create entry-PCs.
Wine canary not yet justified — Linux Debug producing actionable signal.
## Discipline
xenia-rs HEAD `ac2f89a` unchanged. Canary HEAD `6de80dffe` clean (patch reverted). Wallclock ~30 min. Trace at `audit-runs/audit-056-producer-trace/{canary-sub*.log, ours-{parents,ggparents,internal,disp,spawnapi,path}.{jsonl,log}, lr-distribution.csv, final-summary.txt}`.

53
migration/claude-memory/project_xenia_rs_audit_057_thread_gap_2026_05_10.md Normal file
View File

@@ -0,0 +1,53 @@
---
name: AUDIT-057 thread-creation gap characterization 2026-05-10
description: Canary 23 thread spawns / ours 10 / 13 missing in 60s wall + 500M instr respectively. 8 distinct missing-thread spawner fns. Top is sub_825070F0 (4 missing, initializes 4 workers with shared ctx 0xBCE25340, entries 0x82506528/58/88/B8). 11 of 13 missing threads from spawners that don't fire at all in ours — same audit-050 CRT-fnptr-array unreachability pattern. AUDIT-058 = drill into sub_825070F0 activation chain.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-057 (2026-05-10, READ-ONLY, master `ac2f89a` unchanged, canary clean)**: thread-count gap characterization per AUDIT-056 recommendation.
## Thread-spawn diff
Canary 23 fires / ours 10 fires = **13 missing threads**. All have caller-LR=`0x824AC5F0` (kernel-internal `sub_824AC5A8` ExCreateThread wrapper); diagnostically meaningful "spawner" is the originating game fn (r5 = entry-PC of new thread, r4 = ctx).
## Top missing-thread spawners
| Rank | Spawner fn | Missing | Notes |
|---|---|---|---|
| 1 | **`sub_825070F0`** | **4** | Sequential entries `0x82506528/58/88/B8` (+0x30 stride, vtable-shape), shared ctx `0xBCE25340` — 4-worker pool init |
| 2 | `sub_822C6630` | 2 | Spawns `0x822C6870` twice, ctx `0x828F3300` |
| 2 | `sub_823DD838` | 2 | Spawns `0x823DDB50` twice, ctx `0x828F3C88` |
| — | `sub_821C4EB0` | 1 | AUDIT-056 producer (early-return) |
| — | `sub_821746B0` | 1 | Spawns sub_821748F0 twice in canary, once in ours |
| — | `sub_824569C0`, `sub_821701C8`, `sub_823DDD18` | 1 each | Singletons |
8 distinct missing-thread spawner functions total.
## Probe verification (ours --pc-probe over 500M)
- `sub_821746B0`: **fires 1×** (tid=1, frame → sub_82173990 → sub_822F1B50 → 0x8216EE14 → entry_point). Spawns 1 thread but should spawn 2 — missed loop/branch tail.
- `sub_821C4EB0`: **fires 1×** (tid=13 root). Hits entry but early-returns before 5×-cascade (AUDIT-056 finding).
- `sub_825070F0`, `sub_822C6630`, `sub_823DD838`, `sub_824569C0`, `sub_821701C8`, `sub_823DDD18`: **0 fires**
**11 of 13 missing threads** from spawners that don't run at all in ours.
## Activation pattern
None of the 8 missing-thread spawners is statically reachable from entry (`v_reachability_from_entry` = 0 for 7 of them, 1 for sub_824569C0 which still doesn't fire). Same pattern as AUDIT-050 cluster — activated via CRT-driven fnptr arrays (sub_824ACB38 driver enumerates 0x82870xxx arrays). Per AUDIT-050: 14 fnptr arrays / 82 non-NULL fnptrs detected; we know 24 GamePart factory registrations fire via `sub_8280E148`, but other fnptr arrays may not be enumerated correctly.
## Recommended AUDIT-058
**Drill into `sub_825070F0`** (largest single cluster, 4 threads = highest leverage). Probe canary `--log_lr_on_pc=0x825070F0` to capture activation caller. Trace the activation chain backward to find the fnptr array entry that drives it. Compare with ours's CRT-driver enumeration to identify the missing entry.
## Sharp 4-dim cascade prediction (post AUDIT-058 fix)
- A: thread-count 12 → ≥16 (4 new threads spawn) — HIGH confidence
- B: tid=13's wait-on-handle 0x1218 may unblock IF new threads signal 0x1218 — MEDIUM
- C: KeReleaseSemaphore counter rises — MEDIUM
- **D: draws>0** — LOW 10-20% (multiple independent spawner gaps; one fix yields B/C but probably not draws — need several accumulated fixes)
Honest framing: this is a **thread-creation cluster activation problem with multiple independent gaps**. AUDIT-058 likely first of a cluster of cluster-activator fixes.
## Discipline
xenia-rs HEAD `ac2f89a` unchanged. Canary HEAD `6de80dffe` clean post-revert. No stale processes (`pgrep -x` empty after explicit pkill). Trace `audit-runs/audit-057-thread-gap/{canary-ExCreateThread.stdout, ours.stderr, ours-pc-probe.stdout, thread-diff-analysis.csv}`.

50
migration/claude-memory/project_xenia_rs_audit_058_sub825070F0_activation_2026_05_10.md Normal file
View File

@@ -0,0 +1,50 @@
---
name: AUDIT-058 sub_825070F0 activation chain — wedge upstream of cluster 2026-05-10
description: Canary fires sub_825070F0 1× at ~60s wallclock after DiscImageDevice::ResolvePath(\\dat\\movie). Static caller ladder: sub_825070F0 ← sub_824F7800 (vtable bctrl @ 0x824F7B20) ← sub_824F7CD0 ← sub_824F8398 ← sub_821B55D8 ← sub_821B6DF4 (top, 0 callers). ALL 6 ladder fns fire 0× in ours. Break is NOT a CRT-fnptr-array short-circuit — it's the AUDIT-049 main-thread wedge (handle 0x12A4) blocking the entire post-intro phase before sub_821B6DF4 can be activated. Missing piece: vtable 0x8200A208/0x8200A928 has ZERO vptr_writes in DB — the ctor that writes it is in an unreachability island. AUDIT-059 should pivot to the wedge handle rather than continue chasing the static caller ladder.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🎯 KRNBUG-AUDIT-058 (2026-05-10, READ-ONLY, master `ac2f89a` unchanged, canary clean post-revert)**: activation chain analysis for sub_825070F0 (AUDIT-057's top missing-thread spawner, 4 missing threads).
## Canary activation ladder
Canary fires `sub_825070F0` exactly 1× at ~60s wallclock, immediately after `DiscImageDevice::ResolvePath(\dat\movie)` (post-intro file open). Captured: `pc=0x825070F0 lr=0x824F7B24 r3=BCE25340 r4=701CF3C0 r5=BCE25AC0`. Shared-ctx `r3=0xBCE25340` matches AUDIT-057 prediction.
Static caller ladder via `xrefs`:
| Level | Fn | Caller xref | Reach-from-entry |
|---|---|---|---|
| L0 | `sub_825070F0` (vtable[1] of ANON_Class_713383D7) | 0 static callers — vtable-only | False |
| L1 | `sub_824F7800` | `0x824F7B20 bctrl` (computed call); only direct caller sub_824F7CD0 | False |
| L2 | `sub_824F7CD0` | `sub_824F8398 @ 0x824F83D4 bl` | False |
| L3 | `sub_824F8398` | `sub_821B55D8 @ 0x821B5B5C bl` | False |
| L4 | `sub_821B55D8` | `sub_821B6DF4 @ 0x821B6E34 b` (tail) | False |
| L5 | `sub_821B6DF4` | **0 static callers — top of chain** | False |
`bctrl` at 0x824F7B20 has 62 indirect-dispatch candidates in DB but none is sub_825070F0 — static analyzer missed this vtable dispatch. Class `ANON_Class_713383D7` lives at vtables `0x8200A208` (and clone `0x8200A928`); both 7-method tables with sub_825070F0 at slot 1 and **zero recorded vptr_writes** — ctor that writes this vtable is in an unreachability island.
## Where the ladder breaks in ours
Probed all 6 ladder fns in ours via `--ctor-probe` at -n 500M: **ALL 6 fire 0×**. End-state confirms AUDIT-049 main-thread stall (PC 0x824ac578, 5 threads all Blocked on handles 0x12A4/0x12AC/0x1028/0x12B8/0x1020). No `\dat\movie` ResolvePath issued in ours. The break is **upstream of L5** — the entire post-intro phase doesn't activate.
## Three falsifications
(a) **NOT a CRT-fnptr-array short-circuit** of the AUDIT-050 0x82870xxx set. DB has no array in 0x82870000–0x82871000 cataloged at all (CRT driver enumerates raw .data bytes the static disassembler didn't classify). None of the 6 ladder fns is referenced from any cataloged array.
(b) **The break is a wedge, not a short-circuit**. Even sub_821B6DF4 (deepest static-caller-less node) doesn't fire — AUDIT-049's wedge (handle 0x12A4 wait at 0x824ac578) blocks the main thread before activation propagates. Canary's fire happens AFTER intro-movie machinery completes; ours never reaches that phase.
(c) **The actual missing piece is the vtable instance ctor**. sub_825070F0 reached via `r3->vtable[1]` at bctrl `0x824F7B20`. DB has **zero vptr_writes** recording vtables 0x8200A208/0x8200A928 — the ctor that writes them is computed-store-only OR in the unreachability island. Matches AUDIT-050: cluster is half-bootstrapped, vtable-writer subset dead.
## Recommended AUDIT-059
**Pivot from caller-ladder chasing to unblocking the upstream wedge**. The 6-fn ladder isn't actionable in isolation — it's downstream of the AUDIT-049 main-thread stall.
- **AUDIT-059A (surgical)**: extend canary patch to log writes of `0x8200A208`/`0x8200A928` into vptr slots — find the writer ctor. Cross-check ours via `--mem-watch` on the vtable instance address. Cascade: A=writer fires (likely if cluster reaches that phase), B=value matches canary, C=ctor PC identified, **D=draws>0 ~10-20%** (fixing one vtable dispatch unlocks one branch but underlying wedge persists).
- **AUDIT-059B (γ-pivot, preferred)**: per AUDIT-049, handle `0x12A4` is the main-thread wedge handle (created by `sub_821CB030+0x128` NtCreateEvent on tid=13). Audit the producer of the matching NtSetEvent(0x12A4) in canary. This is a γ-cluster pivot.
The most likely productive direction is **treating AUDIT-049 + AUDIT-057 as ONE unified γ-wedge investigation**. The vtable writer in 059A and the missing signaler in 059B may turn out to be the same fn that doesn't execute because the main thread is wedged.
## Discipline
xenia-rs HEAD `ac2f89a` unchanged. Canary HEAD `6de80dffe` clean post-revert. No stale processes. Trace `audit-runs/audit-058-sub825070F0-activation/{canary-sub825070F0.stdout, ours-ladder-probe.{stdout,stderr}}`.

104
migration/claude-memory/project_xenia_rs_audit_2026_05_02.md Normal file
View File

@@ -0,0 +1,104 @@
---
name: xenia-rs comprehensive audit (2026-05-02) — 197 IDs, swap regression solved
description: Complete 13-milestone read-only audit produced 197 finding IDs across 9 prefixes; isolated the post-P8 swap regression to PPCBUG-001 (addi truncation in commit bf8208e); identified VdSwap PM4 ring bypass + 5 P0 GPU shader bugs as renderer-blocker root causes
type: project
originSessionId: a3091846-1196-4ce0-b8b8-b0e57126f1aa
---
## Headline outcome (2026-05-02 session)
**Comprehensive 13-milestone audit of xenia-rs vs xenia-canary as ground truth. Read-only audit (M11 run-matrix had a one-time carve-out for git-bisection, HEAD restored). 197 finding IDs filed across 9 prefixes.**
**Plan**: `/home/fabi/.claude/plans/we-just-did-a-cozy-honey.md`
**Charter**: `xenia-rs/audit-2026-05-charter.md`
**Final report**: `xenia-rs/audit-2026-05-final.md` ← **start here next session**
**Per-milestone reports**: `xenia-rs/audit-out/m{01..11}-*.md` (12 main + 4 M07 sub + 3 M09 sub + 5 M10 sub = ~24 files)
**Master tracker**: `xenia-rs/audit-findings.md` (3789 lines, prior session's PPCBUG entries + new M01-M11 sections)
## SWAP regression SOLVED (2026-05-02)
`SWAPBUG-001` (P0): the post-P8 swaps=2→1 regression is caused by **PPCBUG-001 (addi 32-bit truncation)** in commit `bf8208e` ("Phase 4 batch 3: PPCBUG-001/002/003/004/005/007 4b immediate ALU truncation"). The single `as u32 as u64` cast at `crates/xenia-cpu/src/interpreter.rs:114-118` is canary-divergent — canary does NOT truncate addi. Reverting just that one line restores swaps=2.
Bisection trail (mechanically isolated at -n 100M lockstep):
- pre-P1, P1, P2, P3 → swaps=2
- P4 (commit `d945aea`) → swaps=1 ← regression introduced
- Within P4: commits `f424132`, `e18a0a4`, `145a7a4` → swaps=2; **`bf8208e`** → swaps=1
- Within bf8208e (hunk-level): only PPCBUG-001 revert restores swaps=2; PPCBUG-002/003/004/005/007 reverts leave swaps=1.
Anomaly: PPCBUG-004 (mulli truncation) revert drops `interrupts_delivered` from 629 → 101 but doesn't change swaps. Filed as `SWAPBUG-002` (P2).
## Renderer plateau (`draws=0`) explained (multi-causal)
NOT a memory-subsystem bug. M06 verdict: **same-thread write-visibility is mechanically sound** (`heap.rs` derives `*mut u8` from same `membase` mapping; no per-thread cache; `bump_page_version` Release-store after byte store).
Renderer plateau caused by a multi-component failure at GPU pipeline + kernel↔GPU seam:
1. **VdSwap kernel-bypass** (P0, triple-confirmed): KRNBUG-Vd-04 (M07c) ↔ GPUBUG-001 (M09a) ↔ XMODBUG-013 (M10-X3). Our `vd_swap` zero-fills the reserved 64-dword ring slot with NOPs and calls `state.gpu.notify_xe_swap` directly, bypassing the ring. Canary writes a real PM4 sequence (Type-0 fetch-constant patch + PM4_XE_SWAP). Missing fetch-constant slot 0 means frontbuffer descriptor stays stale; Sylpheed's bloom/blur "sample frame N for frame N+1" path reads garbage.
2. **WGSL shader interpreter operand-decode bugs** (3× P0): GPUBUG-100 (operand modifiers swizzle/abs/neg never read from word-1 — every ALU instr unmodified), GPUBUG-101 (`c#` constant-register selector bit masked off, every shader reads r[low7] instead of constants like WVP matrix), GPUBUG-102 (vertex fetch never applies GpuSwap endian, big-endian VBs decode as garbage).
3. **draw_state register address bugs** (3× P0): GPUBUG-103/104/105. 8 of 26 register addresses misdecoded: VGT_DRAW_INITIATOR, VGT_DMA_BASE, VGT_DMA_SIZE, PA_SC_WINDOW_SCISSOR_TL/BR (reading SCREEN_SCISSOR), RB_COLOR_INFO_1/2/3, PA_SU_VTX_CNTL, index_size from bit 8 instead of bit 11.
**Combined fix queue must land coherently** — partial fixes likely won't unblock visible rendering. See `audit-2026-05-final.md` recommended next sprint.
## Parked-waiter handles (still unexplained)
The 4 worker threads parked on `mr=true,sig=false` events (handles 0x1004, 0x100c, 0x15e4, 0x42450b5c) remain unsolved. M07a confirmed the wake pipeline (`nt_set_event` / `ke_set_event` / `wake_eligible_waiters`) is correct; producer side never fires. M10-X2 ruled out XAMBUG-001 (XamTaskSchedule) as the cause — only called once at startup, before workers spawn.
**Recommended next investigation**: `--trace-handles` audit at -n 5B to confirm zero signals on these handles, then pivot to PPC-level trace of the singleton-handle storage addresses (e.g., 0x828F3F38 for tid=10's event handle in the singleton at +120). Likely intersects M03 PPCBUG-720..735 (control-flow corruption candidates).
## ID summary (all 197)
| Prefix | Total | P0 | P1 | P2 | P3 | Source |
|--------|-------|----|----|----|----|--------|
| ORACBUG | 8 | 1 | 3 | 2 | 2 | M01 (CIRCULAR goldens; sylpheed_n2m.json oracle blind) |
| PPCBUG (new, 701..735) | 32 | 1 | 6 | 7 | 18 | M02-M05 (decoder sound; M03 found regression candidates) |
| MEMBUG | 9 | 0 | 1 | 4 | 4 | M06 (write-visibility NOT broken) |
| KRNBUG | 77 | 3 | 11 | 28 | 35 | M07a/b/c/d (kernel HLE; VdSwap bypass + Mm cluster + Kf no-op) |
| XAMBUG | 16 | 2 | 1 | 7 | 6 | M08 (XamTaskSchedule + 13 async stubs + signin state) |
| GPUBUG | 33 | 6 | 12 | 8 | 7 | M09a/b/c (5 P0 shader/draw + VdSwap confirm + 3 P1 RT/texture) |
| XMODBUG | 22 | 1 | 6 | 5 | 10 | M10-X1..X5 (atomics race + write_bulk skip + IRQ timing seam) |
| ANLBUG | 1 | 0 | 0 | 1 | 0 | M11 (xenia-rs dis doesn't create SQL views by default) |
| SWAPBUG | 2 | 1 | 0 | 1 | 0 | M11 (PPCBUG-001 = swap regression cause; mulli IRQ anomaly) |
| **Total** | **197** | **15** | **40** | **63** | **82** | |
## Key methodology wins
1. **M01 oracle audit FIRST** caught ORACBUG-004 (sylpheed_n2m.json all-zero rendering metrics at -n 2M) before M11 needed to bisect — so M11 used -n 100M instead of -n 2M and the regression was visible.
2. **Hunk-level revert bisection** turned a 6-fix commit into 1-of-6 culprit identification in 12 minutes (~1 build + run per revert).
3. **Cross-module sub-audits independently re-derived findings** — VdSwap-bypass triple-confirmed (kernel/GPU/seam) raised confidence.
4. **M06 ruled out write-visibility** which redirected priority away from a multi-day rabbit hole.
## Run matrix observations (-n 100M)
- **Lockstep reproducibility**: noise floor zero except `packets` (±2.5% from GPU thread race).
- **lockstep + --reservations-table**: ~zero impact on digest at -n 100M.
- **--parallel** crashes interrupts_delivered from 629 → 2 (314× fewer vsync events) AND boosts packets to 3.87B (15× more PM4 work). Confirms KRNBUG-D08 / XMODBUG-011 (VSYNC_INSTR_PERIOD calibration broken under `--parallel`).
- **--parallel + --reservations-table**: pathologically slow (>32 min for -n 100M). Avoid this combo.
## DuckDB state at audit close
- Old DB archived: `xenia-rs/sylpheed.db.apr18.bak` (268 MB, Apr 18).
- Regenerated: `xenia-rs/sylpheed.db` (279 MB, May 2). Row counts identical to Apr 18 — static analysis path is deterministic across the entire P1-P8 audit-fix delta.
- ANLBUG-001 (P2): regenerated DB has NO application views (`v_branch_xrefs`, etc.). The schema-golden test creates them; the user-facing CLI does not (gated on `--analyze=Sql` or `--analyze=Both`, default is `Rust`).
## Workspace state at audit close
- HEAD: `caa37fc` (unchanged from session start).
- Tests: **551 passed, 0 failed**.
- Files modified: only audit output files (`audit-2026-05-charter.md`, `audit-2026-05-final.md`, `audit-out/m*.md`, `audit-runs/`, `audit-findings.md`). Zero `crates/` modifications. `sylpheed.db` regenerated; `sylpheed.db.apr18.bak` archived.
## Recommended next sprint (from audit-2026-05-final.md)
1. **Hour 0**: Revert SWAPBUG-001 (1 line at interpreter.rs:114-118). Confirm swaps=2 returns.
2. **Hour 1-2**: Add sylpheed_n50m.json golden (ORACBUG-004 fix) — protects future fixes from oracle blindness.
3. **Day 1-2**: Renderer P0 batch — VdSwap PM4 ring rewrite (KRNBUG-Vd-04 + GPUBUG-001 + XMODBUG-013).
4. **Day 3-5**: Shader P0 batch — GPUBUG-100/101/102 + GPUBUG-103/104/105 (operand modifiers + constant-reg selector + vertex endian + 8 register addresses). After Day 5, **renderer plateau should break** — Sylpheed should reach first visible frame.
5. **Day 6-7**: KRNBUG-Mm cluster + XAMBUG-001/002.
6. **Day 8+**: VSYNC timing recalibration + remaining P1s.
## Cross-references to prior memory
- Builds on: `project_xenia_rs_ppc_audit_2026_04_29.md` (the prior PPC audit; PPCBUG-001 from THAT audit is now SWAPBUG-001 cause).
- Builds on: `project_xenia_rs_addis_signext_root_cause_2026_04_29.md` (the addis fix; PPCBUG-001 was an over-extension of the same pattern to addi).
- Builds on: `project_xenia_rs_sylpheed_event_chain_2026_04_29.md` (parked-waiter chain; M10-X2 confirmed wake pipeline correct, ruled out XamTaskSchedule).
- Builds on: `project_xenia_rs_sylpheed_stage3_2026_04_29.md` (4-handle parked-waiter map; still unexplained at this audit's depth).

114
migration/claude-memory/project_xenia_rs_audit_2026_05_followup_session.md Normal file
View File

@@ -0,0 +1,114 @@
---
name: audit-2026-05 follow-up session 2026-05-03
description: post-fix-sprint follow-up — 3 audit IDs landed (GPUBUG-DRAIN-001, KRNBUG-AUDIT-001, KRNBUG-D08); parked-waiter producer-trace confirms hypothesis (A) — producer is genuinely missing, not a wake-eligibility bug
type: project
originSessionId: 6e3902ad-3b3c-44e9-9261-badd25e38ae8
---
**🎯 FOLLOW-UP SESSION COMPLETE (2026-05-03)** — 3 audit IDs closed
across 3 commits, all merged to master with `--no-ff`.
**Why**: The 2026-05-03 fix sprint left two visible blockers — the
"PM4_XE_SWAP not consumed by drain" warning under
`--parallel --reservations-table`, and 4 parked-waiter handles
gating `draws=0`. This session diagnosed and fixed the warning,
landed a focused diagnostic that **decisively distinguishes
"missing producer" from "wake-eligibility bug"**, and converted
v-sync to wall-clock under `--parallel`.
**How to apply**: Master HEAD post-session: `b54aa48`. Stable-digest
lockstep -n 100M digest BIT-IDENTICAL to pre-session aa3f1d3.
## Headline data points
- **Tests**: 556 → 561 (+3 wallclock-vsync, +2 ghost-trail)
- **Lockstep `--stable-digest` -n 100M**: bit-identical to master HEAD `aa3f1d3`
(`{instructions:100000002, imports:987685, swaps:2, draws:0, ...}`)
- **`--parallel` PM4 warning**: 2 → **0**
- **`--parallel` interrupts_delivered (-n 30M)**: ~2 → **17** (FIFO cap=4 still throttles)
- **Parked-waiter signal_attempts**: confirmed **0** for all 4 handles after 500M lockstep instructions
## Three commits landed (master post-session HEAD `b54aa48`)
1. **`7a1b6b3`** — `GPUBUG-DRAIN-001` (vd_swap PM4 fallback warning)
- New `GpuSystem::drain_until_wptr(target, time_budget)` mirrors canary `WorkerThreadMain` predicate (ring read != target). Inline `drain_to_current_wptr` switches to it.
- DrainFence handler in worker now publishes the digest mirror BEFORE replying so the CPU's post-drain `digest_snapshot` sees latest stats (was racing the outer-loop publish at line 619).
- **vd_swap NO LONGER injects PM4 packets into the ring**. Tail-injection is unreliable: under `--parallel` either backend, the ring backs up past 4096 / 900 ms before vd_swap can drain to its injected PM4_XE_SWAP packet at the tail. Direct `notify_xe_swap` is now the canonical path. Documented `GPUBUG-FETCH-PATCH-001` as deferred (slot-0 fetch-constant patch — bloom/blur N+1; no observable effect while draws=0).
2. **`d1105aa`** — `KRNBUG-AUDIT-001` (focused parked-waiter ghost-trail diagnostic)
- New `--trace-handles-focus=<LIST>` CLI flag (hex/decimal, comma-separated). Implies `--trace-handles`.
- `HandleAudit` gains `focus: HashSet<u32>` and `ghost_trails: HashMap<u32, GhostTrail>`. `record_signal` auto-falls-through to ghost-trail capture when no primary trail exists AND handle is in focus.
- `dump_thread_diagnostic` emits a "=== Handle audit (focus) ===" section with per-handle DIAGNOSIS conclusions classified by GuestExport / KernelInternal source. `<AUDIT_BLIND>` marker for handles where `waiter_count > 0 && primary_waits == 0` (waiter parked via non-audited path).
- +2 unit tests in `audit::tests` covering ghost-trail behavior.
3. **`27d3608`** — `KRNBUG-D08` (wall-clock v-sync under --parallel)
- `tick_vsync_instr(instr_count)` (legacy, used by lockstep) and `tick_vsync_wallclock()` (new, used by `--parallel`). `KernelState::parallel_active` flag selects.
- Wall-clock fires `floor(elapsed / VSYNC_PERIOD)` v-syncs and advances anchor by full periods (no lazy backlog). Capped at INTERRUPT_QUEUE_CAP per call.
- Lockstep determinism preserved (instr-count proxy is bit-stable; goldens unchanged).
- +3 unit tests covering anchor seeding, single-period fire, burst cap.
## Parked-waiter trace — DECISIVE FINDING
Run: `xenia-rs exec sylpheed.iso --halt-on-deadlock --trace-handles-focus=0x1004,0x100c,0x15e4,0x42450b5c -n 500_000_000` (lockstep, 19 s wallclock).
```
handle=0x00001004 kind=Event/Manual waiters=1 signaled=false
signal_attempts=0 (primary=0, ghost=0) waits=1 wakes=0
created cycle=0 tid=1 lr=0x824a9f6c src=NtCreateEvent
timeline: cycle=0 tid=10 lr=0x824ac578 src=do_wait_single[wait]
GuestExport=0 KernelInternal=0 waits=1
=> producer is a missing kernel signal source (or BST-paradox upstream)
```
Same shape for 0x100c (tid=2) and 0x15e4 (tid=16). Same creator
`lr=0x824a9f6c` for all 3 — single function creates them. Same wait-call
wrapper `lr=0x824ac578` — single wait wrapper. 3 sibling worker threads
all parked on "work-available" notifications.
`0x42450b5c` shows `kind=<UNCREATED>` + `<AUDIT_BLIND>`. It's a
heap-pointer object (per
[stage3 memory](file:///home/fabi/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/project_xenia_rs_sylpheed_stage3_2026_04_29.md))
and the waiter parks via a non-`do_wait_single`/`do_wait_multiple` path.
**KEY CONCLUSION**: For the 3 Event/Manual handles, **the producer is
genuinely missing from the entire 500M-instruction execution**.
Hypothesis (A) confirmed; hypothesis (B) (PPC-vs-Rust BST-paradox)
RULED OUT for these specific handles. The renderer plateau is
**NOT** a wake-eligibility bug — it's a **missing kernel signal
source**.
## Engineering gotchas saved across the sprint
- **`drain_until_wptr` time budget** can fire under `--parallel`+inline (logged at debug because expected). Inline path was the user's `--ui --parallel` invocation; under `--parallel` workloads any inline drain will see 8-10M backlog packets. Time-budget exhaustion is normal there; the warning is for runaway IBs only.
- **DrainFence digest publish race**: outer-loop digest publish at handle.rs ~619 is gated by `did_work` from the per-iteration drive loop; DrainFence handler does NOT set that flag. Without the explicit publish at the end of the DrainFence body, CPU's post-drain `digest_snapshot` returns stale values.
- **Lockstep `interrupts_delivered` was already non-deterministic** — runs of -n 100M produce instructions ∈ {100000001..100000007} and imports ∈ {407665..407669}. The `--stable-digest` view excludes `interrupts_delivered`; `instructions`/`imports` are also excluded from oracle comparison via `--stable-digest`. So Phase 3's wall-clock change under `--parallel` is invisible to the oracle.
- **`KernelState.parallel_active` was added** as a runtime flag set at startup. It now drives `coord_pre_round`'s ticker selection and is the canonical place for any future "behave-differently-under-parallel" decisions.
- **`record_signal` auto-fallthrough to ghost-trail**: a single-line change (in audit.rs) avoided having to wire 8 separate hook sites in exports.rs. Reviewer confirmed this catches all signal sources via `state.audit_signal`.
- **3-handle creator `lr=0x824a9f6c`**: single producer location. Disassemble around that PC to find what function creates the 3 events; that function is also where the producer-trigger code SHOULD be wired but isn't.
- **GPUBUG-FETCH-PATCH-001** (deferred): re-enabling slot-0 fetch-constant patch (canary
`xboxkrnl_video.cc:438-521`) requires a side-channel (e.g. new `GpuCommand::PatchFetchConstant`)
rather than ring injection. Defer until draws > 0 (then bloom/blur N+1 starts to matter).
## Recommended next session
1. **Producer hunt for the 3 Event/Manual handles**. Identify guest function at the shared
wait-call wrapper `lr=0x824ac578`; walk its callers. Find what kernel signal source
SHOULD be wired for each handle. Likely candidates: file I/O completion
(`signal_io_completion_event`), XamTaskSchedule callback (deferred F2), XAudio
buffer-complete (`XAudioRegisterRenderDriverClient` is a one-shot stub), Timer DPC
delivery (KeSetTimer real impl but APC routing may be wrong).
2. **Raise INTERRUPT_QUEUE_CAP** for `--parallel`: 3044 dropped vsyncs at -n 30M --parallel
shows the FIFO is the next bottleneck once wall-clock fires correctly.
3. **F2/F3** (XAM async completion) — especially if Phase 2 of next session pinpoints a
missing XAM producer.
4. **KRNBUG-Mm cluster** still deferred from prior sprint.
## Files of note
- [`xenia-rs/crates/xenia-gpu/src/gpu_system.rs`](xenia-rs/crates/xenia-gpu/src/gpu_system.rs) — new `drain_until_wptr`
- [`xenia-rs/crates/xenia-gpu/src/handle.rs`](xenia-rs/crates/xenia-gpu/src/handle.rs) — inline drain rewire + DrainFence digest publish
- [`xenia-rs/crates/xenia-kernel/src/exports.rs`](xenia-rs/crates/xenia-kernel/src/exports.rs) — vd_swap simplified (no PM4 inject; direct notify)
- [`xenia-rs/crates/xenia-kernel/src/audit.rs`](xenia-rs/crates/xenia-kernel/src/audit.rs) — focus/ghost_trails
- [`xenia-rs/crates/xenia-kernel/src/interrupts.rs`](xenia-rs/crates/xenia-kernel/src/interrupts.rs) — `tick_vsync_instr`/`tick_vsync_wallclock`
- [`xenia-rs/crates/xenia-kernel/src/state.rs`](xenia-rs/crates/xenia-kernel/src/state.rs) — `parallel_active` field
- [`xenia-rs/crates/xenia-app/src/main.rs`](xenia-rs/crates/xenia-app/src/main.rs) — CLI surface + ticker dispatch + DIAGNOSIS report
- [`xenia-rs/audit-findings.md`](xenia-rs/audit-findings.md) — appended "Follow-up session 2026-05-03 — outcome"

72
migration/claude-memory/project_xenia_rs_autonomous_run_synthesis_2026_05_10.md Normal file
View File

@@ -0,0 +1,72 @@
---
name: Autonomous-mode run 2026-05-09/10 — synthesis (audits 044-047)
description: User granted 10 autonomous sessions on 2026-05-09. Sessions 5-8 used (audits 044-047, READ-ONLY). All four refuted speculative hypotheses; no fix landed. Methodological floor reached: every concrete wedge or probe target converges on the audit-009 cluster unreachability island, which is past Linux Debug canary's reach (RECONCILE-B host-presenter block). Sessions 9-10 deliberately NOT consumed — diminishing returns within Linux Debug + READ-ONLY discipline. User hand-back for path selection.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**📋 AUTONOMOUS RUN SYNTHESIS (2026-05-10, hand-back to user)**
User grant on 2026-05-09: "After this session finished I permit you to complete up to ten more sessions on your own, without having to pause and ask for my approval." Sessions consumed in autonomous mode: 044, 045, 046, 047 (counted as 5-8 of 10; sessions 1-4 covered the M1-M12 + 5 closers overhaul work + audit-038 cache fix + audit-041/042/043 wedge probing). Remaining unused: 9-10.
## What the autonomous run produced
### Refuted hypotheses (4)
1. **AUDIT-044 hypothesis "missing cluster constructor sub_8228F858 is bootstrap divergence"** → REFUTED by AUDIT-045 (T1/T2=0/0 in canary at 50s — cluster ctors don't fire in canary either at this horizon).
2. **AUDIT-035 hypothesis "slot-pointer heap-region divergence (canary 0xBC3xxxxx vs ours 0x4024xxxx) is causally responsible for predicate failure"** → REFUTED by AUDIT-046 (predicate at 0x82450904 compares within each engine's own heap region; both engines run identical 5/5 iters and fall through to no-match exit).
3. **AUDIT-034 hypothesis "canary 3.75/5 vs ours 5/5 loop iteration divergence"** → REFUTED by AUDIT-046 at current revision (both engines exhibit identical 5/5 loop shape with 0 early matches).
4. **Implicit "γ-cluster wedge fix can independently open draws cascade"** → REFUTED by AUDIT-047 (best near-reachable signaler `sub_8245AD00` covers 4 wedges, but its callers sit in same audit-009 unreachability island that has blocked every renderer-hunt since audit-009 itself).
### New reading-error class (13th)
**Probe-firing-granularity divergence** (AUDIT-045): xenia-rs `--pc-probe` fires only at basic-block entry; canary `--log_lr_on_pc` fires per-instruction inline in HIR. Mid-block PCs systematically yield ours=0 even when the code executes equivalently. Mitigation: prefer function-entry or post-bl block-entry PCs. Workaround validated in AUDIT-046 (probed `0x82450908` post-bne block-entry instead of mid-block `0x82450904`).
### Confirmed observations (no behavior change but structural truth)
- **Cluster `0x82285000-0x82294000` activation is past Linux Debug canary's 50s horizon** — confirmed by 0/0 fires on cluster ctor PCs in canary AND ours.
- **Audio host-pump gap (AUDIT-032) is dramatic**: KeReleaseSemaphore = 0 ours / 73,914 canary in 90s; all from PC `0x824D229C = sub_824D21F0+0xAC`, all r3=0x828A3230 (XAudio mixer). Already named in AUDIT-032 — a known correctness issue.
- **125 signal-source fns total** (11 direct + 114 wrapper-routed). Only **2 of those 125 are statically reachable AND near a wedge wait-fn**: `sub_8245AD00` (covers 0x10A0/0x10A4/0x1530/0x1534) and `sub_82450218` (covers 0x1040). Both have unreachable callers.
- **Wedge convergence**: 10 NO_SIGNALS_DESPITE_WAITS handles inventoried; per-handle create-LR + wait-LR + expected-signaler tabulated in `audit-runs/audit-047-gamma-wedges/wedge-analysis.csv`.
## What the autonomous run did NOT produce
- No fix landed.
- No `swaps>2` or `draws>0` cascade.
- No new oracle (e.g., Wine/Lutris canary build).
## Methodological floor reached
Within (a) Linux Debug canary as oracle + (b) READ-ONLY discipline + (c) `--pc-probe` and `--log_lr_on_pc` as primary probes, autonomous mode has hit diminishing returns. Every concrete wedge or probe target converges on the same fact: **the audit-009 cluster activation gate is upstream of all visible divergence in Linux Debug canary at the 50s/15min horizons we can reach**.
Linux Debug canary stops at intro-video frame ≈ 42/186 due to Vulkan/XCB host-presenter block (RECONCILE-B); Lutris Windows reaches frame 72/186 but is not instrumentable from our toolset. The cluster activation event happens **after** Linux's stall point.
## Three paths forward (user hand-back)
1. **Wine/Lutris canary build** (HIGH effort, HIGH potential): rebuild xenia-canary under Wine/Lutris on Linux to bypass the Vulkan/XCB host-presenter; rerun audit-045 T1/T2 probes there to capture cluster ctor activation chain post-intro. Requires non-trivial Linux-Wine dev environment setup; canary's CMake/Ninja toolchain must be portable to Wine cross-compile. Risk: high. Reward: only path to NEW evidence within current methodology.
2. **Audio host-pump fix (AUDIT-032 known)** (MEDIUM effort, LOW renderer impact): implement host-side audio worker thread (60-120 LOC mirroring `xenia-canary/src/xenia/apu/audio_system.cc:84-159`) — closes the KeReleaseSemaphore 0-vs-73914 gap. Sharp cascade per AUDIT-032: A=tid 9 unparks on first sub_824D29F0:KeSetEvent(0x828A3254); B=tid 10 unparks on next sema release; C=XAudioSubmitRenderDriverFrame >0; D=KeReleaseSemaphore non-zero. **D=draws>0 explicitly NO** per AUDIT-032 methodology correction. Lands as canary-correctness restoration.
3. **Different probing technique** (HIGH risk): guest-thread injection to force-call cluster ctor entry points and observe what guard predicates fail. Per APUBUG-PRODUCER-001 history, this caused HW-thread hijacks; high risk of regression.
## Recommended user-decision
If the goal is **draws > 0 cascade**, path 1 (Wine/Lutris canary) is the only credible route. Path 2 closes a known gap but explicitly doesn't reach draws. Path 3 is unsafe.
If the goal is **closing canary-correctness gaps without draws focus**, path 2 is bounded and well-characterized. AUDIT-032's sister memory file has the fix sketch.
The autonomous-mode run has done all the diagnostic work it can within its bounds. Sessions 9-10 of the 10-budget remain unconsumed — held in reserve for whichever path the user picks.
## Trace continuity
All four autonomous audits left clean (READ-ONLY) traces:
- `audit-runs/audit-044-m55-cluster-survey/` (DB queries + survey)
- `audit-runs/audit-045-cluster-ctor-probe/` (canary + ours probes)
- `audit-runs/audit-046-loop-exit/` (canary + ours probes)
- `audit-runs/audit-047-gamma-wedges/` (wedge inventory + canary signaler probe)
Memory files: `project_xenia_rs_audit_044_*`, `_045_*`, `_046_*`, `_047_*`. MEMORY.md index updated.
xenia-rs HEAD `7bc9e3a` unchanged across all four audits. Canary `6de80dffe` reverted clean each session. Tests count 645 (preserved from audit-038 baseline). swaps=2 draws=0 plateau intact.

178
migration/claude-memory/project_xenia_rs_cli.md Normal file
View File

@@ -0,0 +1,178 @@
---
name: xenia-rs CLI Reference
description: Complete CLI commands, arguments, and environment variables for the xenia-rs tool — update this when CLI changes
type: project
originSessionId: 08576735-74b4-4180-994a-2eb93dc60997
---
> **Update trigger**: Whenever the xenia-rs CLI changes (new commands, flags, env vars), update this file and the MEMORY.md index entry. Last documented: 2026-04-22 (added `exec --halt-on-deadlock` + `XENIA_HALT_ON_DEADLOCK` env var for deadlock investigation — bypasses the force-wake recovery path so the ctx snapshot survives).
## Binary
`xenia-rs` — Xbox 360 XEX/XISO reverse-engineering toolchain
**CLI framework**: Clap 4.x with derive macros
**Entry point**: `xenia-rs/crates/xenia-app/src/main.rs`
**Observability module**: `xenia-rs/crates/xenia-app/src/observability.rs`
---
## Global flags (apply to every subcommand)
| Flag | Type | Effect |
|------|------|--------|
| `--log-json` | bool | Force JSON on the console fmt layer (default is compact text, stderr) |
| `--log-file <PATH>` | path | Additionally write logs to file via non-blocking appender. `.json` extension → JSON formatter; else text |
| `--log-filter <DIRECTIVES>` | env-filter | Overrides `RUST_LOG`. Precedence: `--log-filter` > `RUST_LOG` > default (`warn` for `exec --quiet`, else `info`) |
| `--trace-chrome <PATH>` | path | Emit Chrome `about:tracing` JSON of all spans (uses `tracing-chrome`). Loadable in `chrome://tracing` / Perfetto |
| `--profile <PATH>` | path | Start pprof sampling profiler at 100 Hz. `.svg` → flamegraph; `.pb` → pprof protobuf. Requires `profiling` Cargo feature (on by default) |
**Cargo features** on `xenia-app`:
- `profiling` (default): pulls `pprof = { features = ["flamegraph", "protobuf-codec"] }`. Disable with `--no-default-features` for minimal release builds; `--profile` then fails at startup with a clear error.
---
## Commands
### `disasm` — Disassemble XEX from entry point
```
xenia-rs disasm <PATH> [-n <COUNT>]
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX file |
| `-n, --count` | usize | 64 | Number of instructions to disassemble |
---
### `exec` — Load and execute XEX with tracing
```
xenia-rs exec <PATH> [-n <MAX>] [--ips-limit <N>] [--db <DB>] [--trace-instructions] [--trace-imports] [--trace-branches] [--quiet] [--ui] [--halt-on-deadlock]
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX file |
| `-n, --max-instructions` | Option\<u64\> | none | Max instructions before stop (unlimited if omitted) |
| `--ips-limit` | Option\<u64\> | none | Throttle to N instructions per second (unlimited if omitted). Check runs once per scheduler round at `run_execution`'s outer loop — anchor is `Instant::now()` at function entry |
| `--db` | Option\<String\> | none | SQLite DB path; includes full static analysis + opt-in trace tables |
| `--trace-instructions` | bool flag | false | Log each instruction to `exec_trace` table |
| `--trace-imports` | bool flag | false | Log kernel/import calls to `import_calls` table |
| `--trace-branches` | bool flag | false | Log taken branches to `branch_trace` table |
| `--quiet` | bool flag | false | Suppress banners, kernel logs, register dump |
| `--ui` | bool flag | false | Open winit+wgpu window for dynamic analysis; backs XamInputGetState with gilrs; presents guest frontbuffer on VdSwap; CPU runs on worker thread. HUD shows swap count + last frontbuffer addr + pad state. Phase 1: no PM4/shader execution, so the frontbuffer is typically black for real games — HUD remains live. |
| `--halt-on-deadlock` | bool flag | false | At the hard-deadlock branch in `run_execution` (all live HW threads `Blocked` on handle waits, no pending timer), emit a per-HW-slot `warn!` with `tid`/`state`/`pc`/`lr`/`sp` and break instead of force-waking waiters with `STATUS_TIMEOUT`. Increments `scheduler.deadlock_halts` metric; sets the UI shutdown flag so the window closes alongside the worker. Default is force-wake (preserved probe-run behaviour — counts as `scheduler.deadlock_recoveries`). Also settable via `XENIA_HALT_ON_DEADLOCK=1`. |
---
### `browse` — Browse XISO disc image contents
```
xenia-rs browse <PATH>
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XISO file |
---
### `info` — Display XEX header information
```
xenia-rs info <PATH>
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX file |
---
### `extract` — Extract PE image and metadata from XEX
```
xenia-rs extract <PATH> [-o <OUTPUT>] [--db <DB>]
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX or ISO file |
| `-o, --output` | Option\<String\> | input dir | Output directory |
| `--db` | Option\<String\> | none | SQLite DB; writes `metadata`, `sections`, `imports` tables |
---
### `dis` — Full disassembly with function detection and xrefs
```
xenia-rs dis <PATH> [-o <OUTPUT>] [--db <DB>] [--quiet]
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX or ISO file |
| `-o, --output` | Option\<String\> | stdout | Output .asm file |
| `--db` | Option\<String\> | none | SQLite DB; includes extract tables + `functions`, `labels`, `instructions`, `xrefs` |
| `--quiet` | bool flag | false | Suppress assembly text output (DB-only mode) |
---
### `check` — Deterministic run digest + golden-diff regression detector (P8)
```
xenia-rs check <PATH> [-n <INSTRS>] [--out <PATH>] [--expect <PATH>]
```
| Arg | Type | Default | Description |
|-----|------|---------|-------------|
| `path` | String (positional) | — | Path to XEX or ISO file |
| `-n, --max-instructions` | u64 | 2_000_000 | Instructions to execute before computing the digest |
| `--out` | Option\<String\> | stdout | Write the 14-field JSON digest to this path |
| `--expect` | Option\<String\> | none | Golden digest JSON; byte-for-byte (trimmed) diff against the run's output. Exits non-zero on mismatch with `expected vs actual` on stderr |
**Digest fields** (stable order, one `u64` per line): `path`, `instructions`, `imports`, `unimpl`, `packets`, `draws`, `swaps`, `resolves`, `unique_render_targets`, `shader_blobs_live`, `interrupts_delivered`, `interrupts_dropped`, `texture_cache_entries`, `texture_decodes`.
**Typical use**: Run once on a known-good build → commit the output as `run.digest.json`. CI re-runs `xenia-rs check … --expect run.digest.json`; non-zero exit blocks the PR on drift.
---
## Environment Variables
### `XENIA_DB_BATCH_SIZE`
- **Source**: `xenia-rs/crates/xenia-analysis/src/db.rs` (lines 35-45)
- **Type**: u64
- **Default**: `100_000`
- **Validation**: Must be > 0; invalid values fall back to default
- **Effect**: Rows per streaming commit / trace buffer flush. `import_calls` always flushes at 1,000 (not configurable).
### `RUST_LOG`
- **Source**: standard `tracing-subscriber` env filter
- **Default behavior**: `"warn"` when `exec --quiet`, otherwise `"info"`
- **Override**: Set to any tracing filter string (e.g. `debug`, `xenia_analysis=trace`)
- **Note**: `--log-filter` takes precedence over `RUST_LOG`.
### `XENIA_FAKE_PAD`
- **Source**: `xenia-rs/crates/xenia-ui/src/input.rs` (`fake_pad_policy`)
- **Default**: enabled (simulated pad when no physical controller)
- **Disable with**: `XENIA_FAKE_PAD=0` (or `false` / `off`)
- **Effect**: when no gilrs pad is attached, `XamInputGetState` still returns `STATUS_SUCCESS` with an all-zero `X_INPUT_STATE` so games don't bail with `ERROR_DEVICE_NOT_CONNECTED`. Set to `0` to get truthful "no controller" reporting.
### `XENIA_SCHED_ORDER` / `XENIA_SCHED_SEED`
- **Source**: `xenia-rs/crates/xenia-cpu/src/scheduler.rs` (`OrderMode::from_env`)
- **Default**: fixed 0..=5
- **Effect**: `random` (with optional u64 `XENIA_SCHED_SEED`) shuffles round order for fuzzing thread interleavings.
### `XENIA_HALT_ON_DEADLOCK`
- **Source**: `xenia-rs/crates/xenia-app/src/main.rs` (resolved at the top of `run_execution`)
- **Values**: `1` or `true` (case-insensitive) to enable; anything else = disabled
- **Default**: disabled (force-wake waiters with `STATUS_TIMEOUT`, increment `scheduler.deadlock_recoveries`)
- **Effect**: equivalent to `exec --halt-on-deadlock`. OR'd with the flag — either source is sufficient to trip the halt path. Use from shells / recipes without rewiring CLI args.
### `RUST_LOG_SPAN_EVENTS`
- **Source**: parsed by `observability::parse_span_events`
- **Values**: `full | close | active | enter | exit | new` (anything else = none)
- **Effect**: Controls the `FmtSpan` setting on fmt layers. `close` is the most useful — every span emits a line with `time.busy`/`time.idle` elapsed, giving per-phase timing in the console without reading a Chrome trace.
---
## Database Table Layering
| Command | Tables |
|---------|--------|
| `extract --db` | `metadata`, `sections`, `imports` |
| `dis --db` | above + `functions`, `labels`, `instructions`, `xrefs` |
| `exec --db` | above + `exec_trace`*, `import_calls`*, `branch_trace`* |
*Only written when corresponding `--trace-*` flag is passed to `exec`.
**Why:** Cumulative schema lets analysis tools query across all levels without joining separate DBs.
**How to apply:** When suggesting DB workflows, recommend the appropriate command tier for the user's analysis goal.

80
migration/claude-memory/project_xenia_rs_concurrency_m1_progress.md Normal file
View File

@@ -0,0 +1,80 @@
---
name: xenia-rs concurrency rollout — M1 complete (2026-04-26)
description: All 10 M1 sub-steps landed. Default GPU backend is now threaded (worker thread on its own); `--gpu-inline` is the rollback. 395 workspace tests pass; sylpheed -n 2M golden matches in both modes; VdSwap=1/=2 fire end-to-end under threaded mode.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## What's landed (M1.1–M1.10)
All 10 M1 sub-steps complete. Default GPU backend at runtime is **threaded** (`GpuBackend::Threaded`); `--gpu-inline` (or `--ui`, or `XENIA_GPU_INLINE=1`) selects the legacy synchronous path.
### Key types and modules
- **`xenia_gpu::GpuBackend`** — enum `Inline(GpuSystem) | Threaded(GpuHandle)`. Forwarding methods: `mmio()`, `as_inline[_mut]()`, `initialize_ring_buffer`, `enable_rptr_writeback`, `extend_write_ptr_by`, `drain_to_current_wptr`, `notify_xe_swap`, `has_pending_interrupts`, `take_pending_interrupts`, `digest_snapshot`. ([crates/xenia-gpu/src/handle.rs](xenia-rs/crates/xenia-gpu/src/handle.rs))
- **`GpuCommand`** — `InitializeRing`, `EnableRptrWriteback`, `DrainFence{target_wptr, reply_tx}`, `NotifyXeSwap{frontbuffer_phys, width, height}`, `Shutdown`.
- **`GpuHandle::send_cmd(cmd)`** wraps the raw `cmd_tx.send` with M1.7 parker discipline (set `wake_pending=true` Release + `unpark()` worker thread).
- **`GpuWorker::run(Arc<GuestMemory>)`** — registers self as wake target, drains commands, syncs MMIO + executes packets in batches of 64, refreshes `Arc<Mutex<GpuDigestSnapshot>>` for the CPU-side digest, drains `pending_interrupts → int_tx`, parks via `park_timeout(16ms)` when idle.
- **`spawn_gpu_worker(worker, Arc<GuestMemory>) -> JoinHandle`** spawns the worker; `shutdown_and_join_with_timeout` joins with 1 s defensive timeout.
### Memory model
- **`GuestMemory.page_table: Vec<AtomicU64>`** with per-page Acquire/Release. `alloc`, `is_mapped`, `page_entry`, `write_bulk`, `translate_virtual_mut` all `&self`.
- **`GuestMemory.writes_total: AtomicU64`** + **`page_versions: Vec<AtomicU64>`** with Release on bump, Acquire on read.
- **`MemoryAccess::write_u32_fence` / `read_u32_fence`** (M1.8) — Release fence before the write / Acquire fence after the read. Migrated `EVENT_WRITE_SHD` and `writeback_read_ptr` to use the fenced variants.
- **All `MemoryAccess` writes take `&self`** post the M1.4(b) handoff. ~140 `&mut GuestMemory` callsites swept across 10 files. `GuestMemoryPcr<'_>` callsites use `&mut` because `PcrWriter::write_pcr_id(&mut self, ...)`.
### Concurrency primitives (live in production)
- **MMIO mailboxes** (`Arc<AtomicU32>` × 5): `cp_rb_wptr`, `cp_rb_rptr`, `cp_int_status`, `cp_int_ack`, `d1mode_vblank_vline_status`. Release on writer / Acquire on reader.
- **`GpuMmio.wake_pending: Arc<AtomicBool>`** + **`worker_thread: Arc<Mutex<Option<Thread>>>`**. WPTR write callback sets+`unpark()`s; worker swaps→park.
- **`crossbeam_channel::unbounded`** for cmd_tx/cmd_rx and int_tx/int_rx.
- **`bounded(1)`** reply channels for `DrainFence` (CPU's `recv_timeout(1s)` + worker's `Instant`-based 900 ms internal deadline).
- **`Arc<Mutex<GpuDigestSnapshot>>`** refreshed once per worker iteration; CPU reads via `digest_snapshot()`.
### CLI / env defaults
```
default → threaded
--gpu-inline (or XENIA_GPU_INLINE=1) → inline
--gpu-thread (or XENIA_GPU_THREAD=1) → threaded (explicit)
--ui → forces inline (UI worker not yet shared-mem-aware)
```
### Verification (all green)
| Check | Result |
|---|---|
| `cargo build --workspace` | clean |
| `cargo test --workspace` | 395 passed, 0 failed |
| `xenia-rs check sylpheed.iso -n 2_000_000 --expect golden/sylpheed_n2m.json` (default = threaded) | matches |
| Same with `--gpu-inline` | matches |
| `xenia-rs exec sylpheed.iso -n 30_000_000 --halt-on-deadlock` (default = threaded) | exit 0 |
| VdSwap=1 + VdSwap=2 under threaded mode | both fire (~18M + ~28M cycles) |
| GPU worker shutdown clean within 1 s | yes |
Beyond ~50M instructions both threaded and inline modes hit the same `RtlRaiseException` pre-existing bug (unrelated to concurrency rollout).
### Known limitations / deferred
- **`--ui` + threaded backend**: `cmd_exec_inner` panics if both are set; `--ui` auto-forces inline. Rationale: `run_with_ui` consumes `GuestMemory` by value; migrating it to `Arc<GuestMemory>` is a separate work item.
- **Inline path retained**: kept as the rollback rail and the `--ui` path. M1.10 cleanup deferred to post-M3 per plan.
- **Beyond ~50M instructions**: both modes hit a pre-existing `RtlRaiseException`. Not a regression.
### Next milestone (M2)
`KernelStateInner + Arc<Mutex<...>>` refactor, per-slot `Mutex<HwSlot>`, `ThreadRef` generation packing, `ReservationTable` for `lwarx`/`stwcx.`. Some M2 work was pulled forward by M1.4 (page_table atomization) — that's already complete.
### Files of note
- [crates/xenia-gpu/src/handle.rs](xenia-rs/crates/xenia-gpu/src/handle.rs) — `GpuBackend`, `GpuCommand`, `GpuHandle::send_cmd`, `GpuWorker::run`, `GpuDigestSnapshot`, parker
- [crates/xenia-gpu/src/gpu_system.rs](xenia-rs/crates/xenia-gpu/src/gpu_system.rs) — `GpuMmio` with `wake_pending` + `worker_thread`; `EVENT_WRITE_SHD` / `writeback_read_ptr` use fenced writes
- [crates/xenia-gpu/src/mmio_region.rs](xenia-rs/crates/xenia-gpu/src/mmio_region.rs) — `CP_RB_WPTR` write callback sets `wake_pending` + `unpark()`s worker
- [crates/xenia-memory/src/heap.rs](xenia-rs/crates/xenia-memory/src/heap.rs) — `Vec<AtomicU64>` page table, `&self` writes
- [crates/xenia-memory/src/access.rs](xenia-rs/crates/xenia-memory/src/access.rs) — `write_u32_fence` / `read_u32_fence`
- [crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs) — `KernelState::with_gpu(GpuBackend)`
- [crates/xenia-kernel/src/exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs) — `vd_swap` rewritten to use `GpuBackend` accessors; UI publish gated on `as_inline_mut()`
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) — backend selection, worker spawn+join, `Arc<GuestMemory>` wrap

123
migration/claude-memory/project_xenia_rs_concurrency_m2_progress.md Normal file
View File

@@ -0,0 +1,123 @@
---
name: xenia-rs concurrency rollout — M2 substantively complete (2026-04-26)
description: M2.1–M2.5 + M2.8 landed; M2.6 (KernelStateInner) + M2.7 (per-slot Mutex<HwSlot>) deferred to M3 because they only matter when host threads exist. Page versions atomic, ReservationTable built (with stress test), ThreadRef carries generation, bump allocators atomic, per-slot pending_local_irq[6] AtomicU8 wired, --reservations-table CLI flag flips runtime atomic. 405 tests pass, sylpheed -n 2M golden matches under all flag combos.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## What landed
### M2.1 — atomic page versions + Acquire/Release for cache invalidation
Already complete from M1.4 — `page_table: Vec<AtomicU64>`, `writes_total: AtomicU64`, `page_versions: Vec<AtomicU64>` in [crates/xenia-memory/src/heap.rs](xenia-rs/crates/xenia-memory/src/heap.rs). Block cache and texture cache call `mem.page_version(...)` which is `Acquire` load on the live `GuestMemory` impl.
### M2.2 — `ReservationTable` for lwarx/stwcx
New module: [crates/xenia-cpu/src/reservation.rs](xenia-rs/crates/xenia-cpu/src/reservation.rs). Banked `Vec<AtomicU64>` (4096 banks × 8 B = 32 KiB), `(line_addr, generation, hw_id)` packed per slot. Hash collisions invalidate conservatively (matches Xenon L2 associativity). Memory ordering: `AcqRel` on the line CAS / swap; `Relaxed` on the active-reserver counter.
API:
- `reserve(addr, hw_id) -> u32` — claim a slot, returns the generation stamped.
- `try_commit(addr, my_gen, my_hw_id) -> bool` — CAS-clear the slot if it still matches.
- `invalidate_for_write(addr)` — plain-store hook to invalidate the line.
- `has_active_reservers() -> bool` — fast-path skip on writes when zero.
9 unit tests including an 8-thread stress test (`concurrent_lwarx_stwcx_serializes`) that proves only one stwcx can win per round. Lives behind `--reservations-table` flag (M2.8); the interpreter's `lwarx`/`stwcx.` arms still use the legacy per-`PpcContext` fields. M3 will hook the table into the interpreter when host threads spawn.
### M2.3 — `ThreadRef` generation packing
[crates/xenia-cpu/src/scheduler.rs](xenia-rs/crates/xenia-cpu/src/scheduler.rs:52-79):
```rust
pub struct ThreadRef {
pub hw_id: u8,
pub generation: u8,
pub idx: u16,
}
```
Total 4 bytes, no padding. 256 reuses per slot before wraparound; `PRUNE_DEPTH_THRESHOLD = 4` keeps slots shallow so this is plenty. M2 leaves generation at `0` on every spawn — no concurrent `swap_remove` happens before M3 so ABA can't occur. M3's migration-fixup site will bump generations.
Constructors `ThreadRef::new(hw_id, idx)` and `ThreadRef::with_generation(hw_id, idx, generation)`. ~30 existing literal sites adapted (several converted to `ThreadRef::new(...)`, others got an explicit `generation: 0` field).
### M2.4 — bump allocators to atomics
In [crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs):
- `next_handle: AtomicU32` (start `0x1000`, `fetch_add(4, Relaxed)`)
- `next_thread_id: AtomicU32`
- `next_tls_index: AtomicU32`
- `heap_cursor: AtomicU32`
- `stack_cursor: AtomicU32`
`heap_alloc` / `stack_alloc` use `fetch_add(size, Relaxed)` then verify post-bump invariants. A failed alloc near the limit leaves the cursor advanced (matches pre-M2 behavior — game-over either way). New unit test `concurrent_alloc_handle_distinct` (10 threads × 100 allocations → 1000 distinct handles).
### M2.5 — per-slot `pending_local_irq` (preview)
In [crates/xenia-kernel/src/interrupts.rs](xenia-rs/crates/xenia-kernel/src/interrupts.rs):
```rust
pub type PendingLocalIrq = [AtomicU8; HW_THREAD_COUNT];
pub struct InterruptState {
// ... existing fields ...
pub pending_local_irq: PendingLocalIrq,
}
```
Field exists, `Default::default()` initializes to all zeros. Unused in M2's lockstep path; M3 will set bits Release on the target slot's atomic and the target T_cpu_i will Acquire-load at quantum boundary.
### M2.8 — reservation table activation flag
`--reservations-table` CLI flag on `Exec` and `Check`. `XENIA_RESERVATIONS_TABLE=1` env var fallback. When set, `kernel.reservations_enabled` flipped to `true` (Release). Always-allocated `kernel.reservations: Arc<ReservationTable>` (every kernel has one; it's free until used).
Interpreter wiring is M3 work — for now the flag is observable but doesn't change `lwarx`/`stwcx.` semantics. Verified: golden matches under `--reservations-table`, `--gpu-inline --reservations-table`, etc.
## Deferred to M3 (with rationale)
### M2.6 — `KernelStateInner` + `Arc<Mutex<...>>`
The plan calls this "the big mechanical step" — change ~98 export signatures from `&mut KernelState` to `&mut KernelStateInner`. **Deferred to M3 because:**
1. Under M2's single-threaded execution, the lock would never contend — the refactor delivers zero observable benefit.
2. The locking discipline (lock per HLE call vs. lock per round) only becomes load-bearing once multiple host threads exist. Designing it without those callers risks designing the wrong API.
3. The M3 spawn work *is* the natural integration point: spawning per-HW-thread workers and granting them concurrent kernel access are inseparable.
Bundled with M3 work on the next session.
### M2.7 — per-slot `Mutex<HwSlot>` + `SchedulerTopology` RwLock
Same rationale: the per-slot mutex is invisible until multiple T_cpu_i exist. The lock-ordering proof from the plan (ascending `hw_id`, topology RwLock above per-slot Mutex) only becomes verifiable under genuine parallelism. Bundled with M3.
## Verification (all green)
| Check | Result |
|---|---|
| `cargo build --workspace` | clean |
| `cargo test --workspace` | 405 passed, 0 failed |
| `xenia-rs check sylpheed.iso -n 2_000_000 --expect golden/sylpheed_n2m.json` (default = threaded) | matches |
| Same with `--gpu-inline` (rollback) | matches |
| Same with `--reservations-table` | matches |
| Same with `--gpu-inline --reservations-table` | matches |
| `concurrent_lwarx_stwcx_serializes` (8 threads × 1000 rounds, ReservationTable stress) | passes |
| `concurrent_alloc_handle_distinct` (10 threads × 100 allocs, AtomicU32 next_handle) | passes |
| `write_u32_fence_publishes_prior_writes` (M1.8 fence test, hardened with AtomicU32 storage) | passes |
Tests grew from 395 (post-M1) to 405 (+10 new substep tests).
## Files of note
- [crates/xenia-cpu/src/reservation.rs](xenia-rs/crates/xenia-cpu/src/reservation.rs) — banked `ReservationTable` with stress tests
- [crates/xenia-cpu/src/scheduler.rs](xenia-rs/crates/xenia-cpu/src/scheduler.rs) — `ThreadRef` gen-packed, `ThreadRef::new` constructor
- [crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs) — atomic bump allocators, `reservations: Arc<ReservationTable>`, `reservations_enabled: AtomicBool`
- [crates/xenia-kernel/src/interrupts.rs](xenia-rs/crates/xenia-kernel/src/interrupts.rs) — `pending_local_irq: [AtomicU8; 6]`
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) — `--reservations-table` flag wiring, kernel construction
- [crates/xenia-gpu/src/handle.rs](xenia-rs/crates/xenia-gpu/src/handle.rs) — fence test fixture rewritten to use `AtomicU32` slots (was flaky `Cell<u8>`)
## Next milestone (M3)
The M3 spawn work bundles:
1. **`KernelStateInner` split** (carryover from M2.6). `Arc<Mutex<KernelStateInner>>`. ~98 export sigs.
2. **Per-slot `Mutex<HwSlot>`** (carryover from M2.7). Lock order ascending by `hw_id`. `SchedulerTopology` RwLock for cross-slot ops.
3. **Phaser primitive** for quantum-based barrier sync.
4. **6 `HwHostThread`s** spawned. Wakeup-on-signal via `slot_wake[6]` + `unpark()`.
5. **IRQ injection routed through `pending_local_irq[6]`** — target T_cpu_i self-injects.
6. **Reservation table activation** in `lwarx`/`stwcx.` arms.
7. **Sylpheed parallel boot** verification + 100x stress test.
The plan's verification matrix at M3 done: golden matches under `--lockstep` (single-host-thread; M2 still matches). Parallel mode reaches VdSwap=2 with `deadlock_halts == 0` (digest *will* differ from lockstep — expected and documented per the existing thread-interleaving-divergence note in the perf memory).

84
migration/claude-memory/project_xenia_rs_concurrency_m3_progress.md Normal file
View File

@@ -0,0 +1,84 @@
---
name: xenia-rs concurrency rollout — M3.1 + per-thread block-cache substrate landed (2026-04-26); M3.2–M3.8 deferred
description: Phaser primitive + per-HW-slot block caches landed (M3.1, M3.2a). The remaining seven substeps (per-slot Mutex<HwSlot>, KernelStateInner split, host-thread spawn, slot wakeups, IRQ routing, reservation interpreter wiring, parallel stress test) are interdependent and require focused dedicated sessions to land safely with per-step verification. Deferred work is precisely scoped below for the follow-up.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## What landed this session
### M3.1 — Phaser primitive
[crates/xenia-cpu/src/phaser.rs](xenia-rs/crates/xenia-cpu/src/phaser.rs). Custom barrier-with-skip; 6 unit tests pass:
- `n_arrivers_all_advance` — basic barrier semantics
- `skip_counts_toward_advance` — skipping participants count toward advance
- `shutdown_wakes_arrivers` — clean tear-down via `Phaser::shutdown()`
- `timeout_fires_when_peer_hangs` — defensive timeout returns `PhaserOutcome::Timeout`
- `multi_phase_progress` — 6 threads × 1000 phases, no deadlock, generation counter consistent
- `mixed_skip_and_arrive_random` — pseudo-random skip/arrive across 200 phases
Memory ordering: phase counter is `Release`/`Acquire`. Participant count under `Mutex` + `Condvar`. The skip-counts-toward-advance design lets idle slots park on their own wake mechanism without stalling the phaser.
### M3.2a — Per-HW-slot block caches
[crates/xenia-app/src/main.rs:1228](xenia-rs/crates/xenia-app/src/main.rs#L1228):
```rust
let mut block_caches: [BlockCache; HW_THREAD_COUNT] =
std::array::from_fn(|_| BlockCache::new());
```
Dispatch site at [main.rs:1651](xenia-rs/crates/xenia-app/src/main.rs#L1651) routes through `block_caches[hw_id as usize]`. Bit-identical correctness in single-threaded mode (it's just 6 independent caches on one thread); eliminates cross-slot races for the eventual host-thread spawn.
Lockstep golden at -n 2M: matches.
## Verification
- `cargo build --workspace`: clean
- `cargo test --workspace`: 411 passed, 0 failed (was 405 post-M2; +6 from phaser tests)
- `xenia-rs check sylpheed.iso -n 2_000_000 --expect golden/sylpheed_n2m.json` (default = threaded GPU): matches
- Same with `--gpu-inline`, `--reservations-table`, `--gpu-inline --reservations-table`: all match
## Why M3.2b–M3.8 are deferred
The remaining substeps are individually invasive and **interdependent** — none of them deliver observable end-to-end value without the others. Splitting them across separate sessions with focused verification is more responsible than racing through them in a single pass.
| Substep | Why it's a focused session of its own |
|---|---|
| **M3.2b** Per-slot `Mutex<HwSlot>` | The scheduler holds `slots: [HwSlot; 6]`; many internal accesses are `&mut self` patterns that don't compose with `MutexGuard` lifetimes. Refactor touches ~30 callsites in `scheduler.rs` + several external accessors that hold borrows across method boundaries. |
| **M3.3** `Arc<Mutex<KernelState>>` wrap | Either wrap the whole struct (~98 export sigs unchanged but every callsite needs guard threading) or split into `KernelStateShared` + `KernelStateInner` (the plan's design — ~98 export sig changes mechanical but workspace-wide). Either path is a substantial single-purpose session. |
| **M3.4** Spawn 6 host threads | Requires M3.2b + M3.3 as substrate. The spawn body itself is a 200–400 line replacement of the per-round portion of `run_execution`. |
| **M3.5** Idle-slot wakeups | Requires M3.4. Adds `slot_wake[6]: AtomicBool` + Thread handles + `unpark()` calls at every `KeSetEvent`/`KeReleaseSemaphore` site. |
| **M3.6** IRQ via `pending_local_irq` | Requires M3.4. M2.5 already wired the AtomicU8 array; M3.6 changes the producer side (T_main / GPU thread sets bits) and consumer side (T_cpu_i checks bits at quantum boundary, self-injects). |
| **M3.7** Activate reservations in interpreter | Requires threading `hw_id` + `Arc<ReservationTable>` reference into the interpreter dispatch. PpcContext doesn't currently carry `hw_id`, and `step`/`step_cached`/`step_block` don't take a table. Each path needs a parameter, and there are many test callers. |
| **M3.8** 100× parallel stress test | Requires M3.4–M3.7. |
## What's already in place from M1+M2 that M3 will use
- **Page versions atomic** (M1.4/M2.1): `Vec<AtomicU64>`, Release/Acquire on per-page slots.
- **Page table atomic** (M1.4): `Vec<AtomicU64>`, lock-free `alloc(&self)`.
- **`MemoryAccess::write_u32_fence` / `read_u32_fence`** (M1.8): Release/Acquire fence helpers used by EVENT_WRITE_SHD / RPTR writeback.
- **GPU on its own host thread** (M1.4–M1.10): `Arc<Mutex<GpuDigestSnapshot>>` + parker via `Arc<AtomicBool>` `wake_pending` + `unpark()` from MMIO callback.
- **`ReservationTable`** (M2.2): banked AtomicU64, 4096 banks, `(line, generation, hw_id)`. Stress-tested with 8 concurrent host threads. Lives at `kernel.reservations: Arc<ReservationTable>`. Activation flag at `kernel.reservations_enabled: AtomicBool` (settable via `--reservations-table` or `XENIA_RESERVATIONS_TABLE=1`).
- **`ThreadRef` generation packing** (M2.3): 1+1+2 = 4 bytes; `::new(hw_id, idx)` constructor.
- **Atomic bump allocators** (M2.4): `next_handle`, `next_thread_id`, `next_tls_index`, `heap_cursor`, `stack_cursor` all `AtomicU32`.
- **`pending_local_irq: [AtomicU8; 6]`** (M2.5): wired in `InterruptState`; M3.6 will start using bits.
- **Phaser primitive** (M3.1): `arrive_and_wait` / `skip` / `shutdown` / `arrive_and_wait_timeout` API.
- **Per-HW-slot block caches** (M3.2a): `[BlockCache; 6]` indexed by `hw_id`.
## Next session resumes at M3.2b
The natural ordering for the deferred work:
1. **M3.2b** Per-slot `Mutex<HwSlot>`. The scheduler internally locks per slot; external API stays method-based (no guard leakage). Verify lockstep golden bit-identical.
2. **M3.3** `Arc<Mutex<KernelState>>` wrap (start coarse — single mutex around the whole struct; refine later if needed). Verify lockstep golden.
3. **M3.4** Spawn N host threads under `--parallel` flag. Each acquires the kernel lock for HLE, drops for instruction execution, syncs at the phaser. Verify sylpheed boots; halts==0.
4. **M3.5** Slot wakeup primitives. M3.4 will park on idle; M3.5 unparks on signal.
5. **M3.6** IRQ routing per slot.
6. **M3.7** Reservation interpreter wiring. PpcContext gets `hw_id` field + `Option<Arc<ReservationTable>>`.
7. **M3.8** 100× sylpheed stress run.
## Files of note
- [crates/xenia-cpu/src/phaser.rs](xenia-rs/crates/xenia-cpu/src/phaser.rs) — phaser primitive (M3.1)
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) — per-thread block caches (M3.2a) at lines 1228 and 1651
- [crates/xenia-cpu/src/lib.rs](xenia-rs/crates/xenia-cpu/src/lib.rs) — re-exports `Phaser`, `PhaserOutcome`

44
migration/claude-memory/project_xenia_rs_cpp_runtime_audit_2026_05_06.md Normal file
View File

@@ -0,0 +1,44 @@
---
name: C++ runtime audit (CPPBUG-AUDIT-001) 2026-05-06
description: Read-only audit of MSVC C++ runtime support in xenia-rs vs canary. Top-3 candidates for explaining audit-011's vtable=0 finding REFUTED by audit-012 (vtable is correctly initialized; misread on audit-011's part). Independent correctness gaps remain as background-work backlog.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🔍 CPPBUG-AUDIT-001 (2026-05-06, READ-ONLY)** — comprehensive audit of MSVC C++ runtime support. Spawned in parallel with audit-012 to investigate "missing C++ runtime features" hypothesis for the audit-011 vtable=0 symptom. Audit-012 falsified the vtable=0 premise itself, so this audit's Top-3 candidates are moot for THAT specific bug — but several real correctness gaps were identified as background work.
## Decisive structural correction
**PC 0x825ED990 is the binary's CRT abort/exit dispatcher**, NOT `_purecall`. Disasm at 0x825ED990..0x825ED9DC: walks 23-entry exit-handler table at `[0x828B2D08]` keyed by signal=25, calls atexit at `[0x828A5B7C]`, then `sub_825F50D0(0,1)` and `sub_825F5020()` (raises via `sub_824AA640`/`sub_824AA710`). MSVC `abort()` / `_amsg_exit` equivalent. Corrects audit-010's "apparent __purecall/abort handler" attribution carried since.
**Sylpheed has its CRT statically linked.** Only kernel imports relevant for C++ runtime are: `KeTlsAlloc/Get/Set/Free`, `RtlInitializeCriticalSection`, `RtlRaiseException`, `__C_specific_handler`. The C++ runtime question is narrower than initially feared.
## Top-3 candidates (REFUTED by audit-012)
1. `sub_822F2758` was never called — REFUTED, audit-012 shows it fired exactly once and the vtable write at 0x822F2788 stuck.
2. Ctor ran but `stw` silently dropped (`nt_allocate_virtual_memory` + `heap.rs:465` silent-drop combo) — REFUTED, write transitions show monotonic 0 → 0x820AD894 → 0x820A183C.
3. Throw inside ctor bypasses unwind (`RtlRaiseException` stub) — REFUTED, no zeroing event observed across 500M.
## Independent correctness gaps (real, not blocking renderer hunt)
| Area | Issue | File:line |
|------|-------|-----------|
| `nt_allocate_virtual_memory` | Returns SUCCESS on alloc failure for non-overlap reasons (page-misalign, out-of-range) | exports.rs:622-625 |
| `heap.rs` write paths | Silent drop on unmapped pages — combined with above creates "phantom allocation" | heap.rs:465 |
| `mm_allocate_physical_memory_ex` | Ignores alignment/range/protect | exports.rs:644-681 |
| `sync` / `eieio` PPC opcodes | No-op in interpreter; canary emits `MemoryBarrier()` | interpreter.rs:1697 vs canary ppc_emit_memory.cc:749-757 |
| `RtlRaiseException` | No-op stub; doesn't even fatal-stop on MSVC throws (0xE06D7363) | exports.rs:2218-2221 |
| TLS storage | Uses `Vec<u64>`; canary uses u32. Functionally OK. | xboxkrnl_threading.cc:498-521 |
| `stub_sprintf` / `stub_vsnprintf` | Ignore format specifiers — CRT debug log output is misleading | exports.rs |
| Heap | Bump-only, no free | state.rs:701-719 |
## Top-leverage diagnostic for future use
TRACE-gated log on unmapped writes in `heap.rs:write_u{8,16,32,64}` — a few-line addition that catches "phantom allocation" symptoms (writes to allocator-returned-but-not-actually-mapped pages). Should be standing infrastructure given the silent-drop class of bugs.
## How to use this memory
When audit-012's listener fix lands and the cascade resumes, the renderer-side bugs that surface may interact with the gaps above (esp. memory ordering / `sync` semantics for cross-thread GPU-CPU). Treat this as a checklist for "first things to suspect" once draws > 0 lands.
These items are NOT urgent for the swap=2 / draws=0 plateau. Track as background-work backlog.
Master HEAD `50a4887` unchanged. No commits. No code modified.

76
migration/claude-memory/project_xenia_rs_current_state.md Normal file
View File

@@ -0,0 +1,76 @@
---
name: xenia-rs current state — boot/render progress + active blockers
description: Where Sylpheed boot sits now (2026-04-24 — IRQ-injection stack-pad + full-volatile register save fix lands; second VdSwap fires)
type: project
originSessionId: 5465978c-b9ad-47fb-ab6d-e8e3053646af
---
## What works end-to-end (2026-04-24)
Sylpheed **now reaches its second `VdSwap` (first real frame)**. Previous sessions stopped at the splash frame (`VdSwap=1`) because our graphics-interrupt injection was stomping the interrupted thread's stack-saved LR — see "Root cause" below.
Observed after the fix, at 3 B instructions:
- `VdSwap frame=1` splash at ~18 M cycles, `VdSwap frame=2` at ~28 M cycles
- `scheduler.deadlock_halts = 0`, `deadlock_recoveries = 0` (clean)
- All 351 workspace tests green
- tid=5 stays alive past cycle 7.5 M (was exiting there pre-fix)
- `RtlEnterCriticalSection` / `LeaveCriticalSection` dropped ~1300× versus pre-fix (was the symptom of the corruption, not the cause)
## Root cause — IRQ injection was stomping `[r1 - 8]` on the interrupted thread's stack
The graphics-interrupt injector (`try_inject_graphics_interrupt` in [main.rs](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-app/src/main.rs)) overwrote `pc`/`lr`/`r3`/`r4` on whichever thread it picked, but left `r1` (SP) untouched. The ISR callback's prologue immediately does `mflr r12; bl __savegprlr_N` where `__savegprlr_N` stores `r12` (= `LR_HALT_SENTINEL`, just set by injection) at `[r1 − 8]`. That slot is **exactly where the interrupted function's own prologue had saved its caller's return address** (standard PPC savegprlr layout). When the interrupted function eventually ran its `__restgprlr_N` tail → `bclr`, it loaded `SENTINEL` into LR and jumped there, silently terminating the thread through the halt-sentinel path rather than the intended return.
Observed concretely: tid=5 hit `LR_HALT_SENTINEL` via `from_pc=0x825f0ff0` (the shared `restgprlr` bclr) with `r12=0xBCBCBCBC` — i.e. the value it just read from the stack at `[r1 - 8]`. Six normal vsync-ISR returns had `ctr=0x821753c8` (ISR-path resolved correctly); the 7th exit had `ctr=0x00000000` — this one was `sub_82458B90` returning with the stack-saved LR clobbered. Matches canary's workaround at [`Processor::Execute`](../../../RE%20Project%20Sylpheed/xenia-canary/src/xenia/cpu/processor.cc#L383) (lines 381–394) which decrements `r[1]` by 64 + 112 = 176 before calling the ISR callback and restores after — the comment says "games seem to overwrite the caller by about 16 to 32b," with the pad sized generously.
## The fix (2026-04-24)
[`CALLBACK_STACK_PAD = 176`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-kernel/src/interrupts.rs) applied in two places:
1. **`SavedCallbackCtx`** now captures/restores **all PPC volatile GPRs** (`r0`, `r2`–`r12`) plus `r1` (SP), `pc`, `lr`, `ctr`, and `cr`. The non-volatile set (`r13`–`r31`) is preserved by the callback's own `__savegprlr_N` prologue/epilogue per the PPC ELF ABI, so it doesn't need stashing.
2. `try_inject_graphics_interrupt` decrements `ctx.gpr[1]` by `CALLBACK_STACK_PAD` **after** `SavedCallbackCtx::capture` (so the saved `r1` is the pre-inject value) and **before** setting `pc = callback_pc`. The callback now prologues into `[injected_r1 − 176 − 8]` instead of stomping `[injected_r1 − 8]`. On return, `SavedCallbackCtx::restore` puts `r1` back.
Thin unit-test coverage: the existing `inject_restore_roundtrip_smoke` test in [interrupts.rs](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-kernel/src/interrupts.rs) still passes (just a smoke test for pc/lr/r3-r4 roundtrip); extending it to cover the new SP + r0/r2/r7-r12 paths would be a cheap follow-up.
## Concrete next-session blockers (post-fix)
tid=5 is now alive, progresses through multiple work items, and drives the data-stream decoders (`sub_8280AD40` = inflate, `sub_828085E0` = Adler-32, `sub_82807AB8` = CRC-32 — all around 0x82807-0x8280C). Observed behaviour at 3 B instructions:
1. **Sylpheed boot is CPU-bound on stream decode.** At 10 MIPS interpreter throughput, the per-asset inflate + Adler/CRC passes eat multi-seconds of wall time each. Second `VdSwap` fires at ~28 M cycles (~3 s wall). For first-pixels to be visually obvious (dozens of frames), we likely need the Tier-4 JIT or at least threaded-code dispatch. Order of magnitude: real HW boots Sylpheed to menu in ~2–3 s at ~200 MIPS; we're ~20× slower.
2. **wgpu→ShadowEdram RT readback** (P1 from prior memory) — frame-2+ blocker once draws fire. See [edram-resolve-gap memory](project_xenia_rs_edram_resolve_gap.md).
3. **Keep verifying with `exec --halt-on-deadlock -n 500_000_000`** — still clean post-fix. Any regression here means a new sync bug.
## Investigation tools available
- **`dump_thread_diagnostic`** (from 2026-04-23b) — prints per-thread state + handle/CS waiter maps at normal `-n N` exit. Now also dumps r0–r13 for every thread (expanded 2026-04-24).
- **`disasm --at <addr> -n N`** — unchanged.
- **DuckDB xrefs** — see [project_xenia_rs_duckdb.md](project_xenia_rs_duckdb.md).
- **PC → LR_HALT_SENTINEL tracer pattern** — reference impl in `2026-04-24` diff on [main.rs](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-app/src/main.rs); was instrumental for this fix. Reverted after use.
- **Adler/CRC entry probes** — one-shot `tracing::warn!(target: "adler_probe", ...)` at the `pc == 0x828085E0 && tid == 5` site. Logs lr/r3/r4/r5 at entry. Reverted after use.
## Confirmed NOT the issue (verified this session)
- `VdCallGraphicsNotificationRoutines` stub — canary matches, Sylpheed doesn't register notifications.
- `NtSetEvent` / `KeSetEvent` return-value semantics — match canary.
- Graphics-interrupt injection per-vsync — fires correctly, delivered counter scales with `VSYNC_INSTR_PERIOD = 150_000`.
- Ring-buffer write-back — correct.
- PKEVENT shadow refresh — correct.
- Event/semaphore handle table — correct; the pre-fix "main stuck on 0x10fc" was a *symptom* of tid=5 dying before producing the signal, not a handle-table bug.
## Architectural patterns (stable, don't re-derive)
- **Scheduler + HW slots + ThreadRef** — see [project_xenia_rs_scheduler.md](project_xenia_rs_scheduler.md).
- **UI bridge + GPU pipeline + MMIO + HUD** — see [project_xenia_rs_ui.md](project_xenia_rs_ui.md).
- **PKEVENT shim** — `ensure_dispatcher_object` reads DISPATCHER_HEADER type on first touch.
- **IRQ injection stack discipline** (new 2026-04-24): the injected callback runs on a **176-byte-padded extension** of the interrupted thread's stack. `SavedCallbackCtx` captures/restores r0, r1, r2–r12 + pc/lr/ctr/cr. Non-volatile regs (r13–r31) are not in the save set because the callback prologue handles them. Canary's Processor::Execute uses the same 64+112 pad.
- **Main thread return ≠ emulator halt** — unchanged.
## Memory-model caveats
- `pending_timer_fires` is keyed by handle (u32). `NtClose` / `NtCancelTimer` / `NtSetTimerEx` manage lifecycle. (Sylpheed doesn't use timers on the boot path.)
- `waiters_mut()` on `KernelObject` returns `None` for `File` and `Some` for the 5 sync variants.
- Handle allocator starts at `0x1000`, bumps by 4.
## Files touched in the 2026-04-24 session
- `xenia-kernel/src/interrupts.rs` — `SavedCallbackCtx` expanded to `gprs: [u64; 13]` (r0–r12), added `CALLBACK_STACK_PAD = 176` constant with docs citing canary as ground-truth.
- `xenia-app/src/main.rs` — `try_inject_graphics_interrupt` now `ctx.gpr[1] -= CALLBACK_STACK_PAD` after capture, before setting callback PC. `dump_thread_diagnostic` expanded to print r0/r3–r13.

10
migration/claude-memory/project_xenia_rs_desktop_app.md Normal file
View File

@@ -0,0 +1,10 @@
---
name: xenia-rs desktop app design
description: UI/UX design decisions for the xenia-rs desktop app — feature groupings and view layout
type: project
originSessionId: c12e8acc-6326-4933-9263-32745c4b1219
---
The disassembler, debugger, analyzer, and executor share a single unified view in the desktop app. Their purposes and underlying data are related/overlapping, so they are not treated as separate panels or tabs.
**Why:** The user explicitly stated this during the overview drafting phase.
**How to apply:** When writing UI copy, feature descriptions, or design docs, describe these four as one combined "Analysis Workspace" rather than four separate features.

79
migration/claude-memory/project_xenia_rs_disasm_unify_phase1.md Normal file
View File

@@ -0,0 +1,79 @@
---
name: Disassembler unification — Phase 1 complete (2026-04-27)
description: Single source of truth for PPC text formatting now lives in xenia-cpu/disasm.rs. xenia-analysis/ppc.rs is a thin shim. DecodedInstr stays at 8 bytes. VMX128 bug fixed.
type: project
originSessionId: 680cc54c-e77a-4d2d-a11b-ca562e9a68ec
---
**Phase 1 of disassembler unification is COMPLETE** (2026-04-27, single session).
## What's in place
- **[crates/xenia-cpu/src/disasm.rs](crates/xenia-cpu/src/disasm.rs)** is the single source of truth for PPC text formatting (~1100 LOC, was 313). Hosts:
- `pub struct DisasmText { mnemonic, operands, disasm, ext_mnemonic, ext_operands, ext_disasm, branch_target }` — all `String` / `Option<String>` / `Option<u32>`. Owns its strings.
- `pub fn format(&DecodedInstr) -> DisasmText` — the canonical formatter. Dispatches via match on `PpcOpcode` to ~70 per-class helpers.
- `pub fn disassemble(&DecodedInstr) -> String` — back-compat: returns `format(...).display().to_string()`.
- `pub fn disassemble_block(...)` — back-compat range walker.
- 8 unit tests covering nop/li/mr/blr/branch-target/rlwinm-dot.
- **[crates/xenia-cpu/src/lib.rs](crates/xenia-cpu/src/lib.rs)** re-exports `DisasmText`, `disassemble`, `format as disasm_format`.
- **[crates/xenia-analysis/src/ppc.rs](crates/xenia-analysis/src/ppc.rs)** collapsed from 1374 LOC → ~30 LOC. Pure shim:
```rust
pub struct Decoded { pub base: String, pub ext: Option<String> }
pub fn disasm(instr: u32, addr: u32) -> Decoded { ... }
```
Delegates to `xenia_cpu::decoder::decode` + `xenia_cpu::disasm::format`.
- **[crates/xenia-analysis/src/db.rs](crates/xenia-analysis/src/db.rs)** call sites use `xenia_cpu::disasm::format` directly. The `split_disasm` helper at the bottom is **deleted** — `DisasmText` exposes mnemonic/operands separately.
- **[crates/xenia-analysis/src/formatter.rs](crates/xenia-analysis/src/formatter.rs)** unchanged — uses the `crate::ppc::disasm` shim's `display()` method.
- **[crates/xenia-analysis/Cargo.toml](crates/xenia-analysis/Cargo.toml)** now depends on xenia-cpu.
## Constraint #1 honored: DecodedInstr unchanged
- `DecodedInstr` is still 8 bytes (`opcode: PpcOpcode`, `raw: u32`, `addr: u32`), `Copy`, no allocations.
- Decode cache at [decoder.rs:228](crates/xenia-cpu/src/decoder.rs) still 64K × 20 bytes = 1.3 MiB.
- `DisasmText` is the new struct that owns the formatted strings, allocated only when `format()` is called from a sink.
## Silent bug fixed: VMX128 register extractors
The pre-Phase-1 `xenia-analysis/src/ppc.rs` had **wrong bit positions** for `va128`/`vb128`/`vd128` compared to `decoder.rs`. The interpreter (which executes guest code) used decoder.rs's correct extractors, so guest behavior was correct — but `.asm` text output and DuckDB rows could show wrong VMX128 register names. Phase 1 routes all VMX128 formatting through `instr.va128()`/`vb128()`/`vd128()` accessors (decoder.rs canonical). Fixed silently.
## Other extended forms now in xenia-cpu
Ported from ppc.rs onto `DecodedInstr` accessors: li/lis/subi/subis, nop, mr/not, slwi/srwi/clrlwi/clrrwi/rotlwi/extlwi/extrwi, clrldi/clrrdi/srdi/sldi/rotldi, insrdi, inslwi/insrwi, cmpwi/cmpdi/cmplwi/cmpldi, cmpw/cmpd/cmplw/cmpld, mflr/mfctr/mfxer, mtlr/mtctr/mtxer, mtcr, mftb/mftbu, blr/blrl/bctr/bctrl, b{cond}{l}{a} (eq/ne/lt/le/gt/ge/so/ns), bd{n}z{cond}, b{cond}lr, b{cond}ctr, sub/subc, crnot/crclr/crset/crmove, lwsync, trap, td{cond}/tw{cond}, td{cond}i/tw{cond}i.
## Behavior changes visible to users
1. `xenia disasm` (the simple subcommand) now emits **extended/simplified mnemonics**. Before Phase 1 it only emitted base forms. Smoke test confirmed: `mr`, `subi`, `nop`, `lis`, `li`, `cmpwi`, `beq`, etc. all appear correctly.
2. VMX128 register names printed in `.asm` and DB are now correct (silent bug fix).
3. MD-form rotate `sh` value display matches decoder.rs's bit layout (was different in old ppc.rs — likely also a silent bug, since the decoder is what runs on guest code).
## Verification done
- `cargo build --workspace` clean (no new warnings; pre-existing warnings in block_cache.rs and vmx.rs unchanged).
- `cargo test -p xenia-cpu` — 166 + 8 new disasm + 9 audit = all pass.
- `cargo test -p xenia-analysis` — audit pass.
- Smoke `xenia disasm <iso> -n 30` — produces clean extended-mnemonic output.
- Full `xenia dis --db` end-to-end deferred to next session (release build was slow; functional path verified by passing cargo tests).
## LOC delta (Phase 1)
- xenia-cpu/src/disasm.rs: +780 (313 → ~1093)
- xenia-analysis/src/ppc.rs: −1344 (1374 → 30)
- xenia-analysis/src/db.rs: −18 (deleted split_disasm + simplified call sites)
- xenia-cpu/src/lib.rs: +1 (re-export)
- xenia-analysis/Cargo.toml: +1 dep
- **Net: −580 LOC** plus single-source-of-truth.
## What's next (Phases 2-4)
Per [/home/fabi/.claude/plans/ok-execute-your-proposed-refactored-dolphin.md](plan):
- **Phase 2**: Iterator + sinks (`iter_disasm` in xenia-cpu, RichDisasmItem enrichment + 3 sinks: text, JSON, DuckDB in xenia-analysis).
- **Phase 3**: Split db.rs into ingest + analyze; add SQL views layer (`v_branch_xrefs`, `v_call_graph`, `v_reachability_from_entry`, etc.) and `--analyze=rust|sql|both` flag. Keep Rust passes as default.
- **Phase 4**: Replace println-only audits with assert-based fixture goldens (`base_mnemonics.json`, `extended_mnemonics.json`, `vmx128_registers.json`, `db_schema_golden.rs`, ISO-gated `disasm_first_1000.json`).
**Format style locked**: Phase 1 reproduces ppc.rs's padded comma-space style (`"addi r3, r4, 16"`). Phase 4 fixtures should lock this.
**LOC budget remaining**: Phase 2 ~+250/-250 (net 0), Phase 3 ~+280, Phase 4 ~+395 (mostly tests/fixtures).

97
migration/claude-memory/project_xenia_rs_disasm_unify_phase2.md Normal file
View File

@@ -0,0 +1,97 @@
---
name: Disassembler unification — Phase 2 complete (2026-04-27)
description: Iterator + 3 sinks (text/JSON/DuckDB) layered over Phase 1's format(). New `xenia dis --json` subcommand. db.rs and formatter.rs both drive through enrich_section.
type: project
originSessionId: 680cc54c-e77a-4d2d-a11b-ca562e9a68ec
---
**Phase 2 of disassembler unification is COMPLETE** (2026-04-27, same session as Phase 1).
## What's in place
### xenia-cpu (decoder + iterator)
- **[crates/xenia-cpu/src/disasm.rs](crates/xenia-cpu/src/disasm.rs)** adds:
- `pub struct DisasmItem { addr, raw, opcode, text }` — yielded by the iterator.
- `pub fn iter_disasm(image, image_base, va_start, va_end) -> impl Iterator<Item = DisasmItem>` — walks bytes in PPC big-endian, decodes via `decoder::decode`, formats via `format`, yields one `DisasmItem` per 4-byte word. Stops on truncated tail.
- 2 new unit tests: `iter_disasm_walks_byte_slice_in_order`, `iter_disasm_stops_on_truncated_tail`.
- **[crates/xenia-cpu/src/lib.rs](crates/xenia-cpu/src/lib.rs)** re-exports `DisasmItem`, `iter_disasm`.
### xenia-analysis (enrichment + sinks)
- **[crates/xenia-analysis/src/disasm.rs](crates/xenia-analysis/src/disasm.rs)** (NEW, ~50 LOC):
- `pub struct RichDisasmItem<'a> { item, section, function, label }` — adds analysis context.
- `pub fn enrich_section(image, image_base, section_name, va_start, va_end, func_analysis, labels) -> impl Iterator<Item = RichDisasmItem<'a>>` — wraps `iter_disasm` with rolling-window function tracking + label lookup.
- **[crates/xenia-analysis/src/sinks/mod.rs](crates/xenia-analysis/src/sinks/mod.rs)** (NEW): module declarations.
- **[crates/xenia-analysis/src/sinks/duckdb.rs](crates/xenia-analysis/src/sinks/duckdb.rs)** (NEW, ~30 LOC): `append_instructions(appender, items) -> Result<u64>` — DuckDB Appender call per row.
- **[crates/xenia-analysis/src/sinks/json.rs](crates/xenia-analysis/src/sinks/json.rs)** (NEW, ~60 LOC): `write_jsonl<W: Write>(out, items) -> io::Result<u64>` — one JSON object per line. Internal `JsonRow<'a>` derives Serialize; uses `#[serde(skip_serializing_if = "Option::is_none")]` to keep rows compact.
- **[crates/xenia-analysis/src/sinks/text.rs](crates/xenia-analysis/src/sinks/text.rs)** (NEW, ~50 LOC): `write_instr_line<W: Write + ?Sized>(out, item, labels, sections, image_base, data_annotation)` — renders one .asm line with branch-target / data-ref annotation. Uses the structured `branch_target` field (not a regex over the disasm string — cleaner than the old `annotate_branch`).
- **[crates/xenia-analysis/src/lib.rs](crates/xenia-analysis/src/lib.rs)** declares `disasm` and `sinks` modules; re-exports `RichDisasmItem` and `enrich_section`.
- **[crates/xenia-analysis/Cargo.toml](crates/xenia-analysis/Cargo.toml)** adds `serde_json = { workspace = true }` dep.
### Refactored call sites
- **[crates/xenia-analysis/src/db.rs](crates/xenia-analysis/src/db.rs)** `insert_instructions_streaming` collapsed from a 50-line byte loop into 12 lines: `for section { let items = enrich_section(...); total += sinks::duckdb::append_instructions(&mut appender, items)?; }`.
- **[crates/xenia-analysis/src/formatter.rs](crates/xenia-analysis/src/formatter.rs)** code-section loop collapsed: now iterates `enrich_section` and calls `write_instr_line` for the per-line render. Orchestration (function headers, labels, xref comments, import annotations) stays in formatter.rs. The old `annotate_branch` helper is **deleted** — branch-target annotation lives in the text sink and uses `branch_target: Option<u32>` from `DisasmText`.
### CLI
- **[crates/xenia-app/src/main.rs](crates/xenia-app/src/main.rs)**: new `--json <path>` flag on `dis` subcommand. Writes JSON Lines via `sinks::json::write_jsonl` per code section. Wires through `cmd_dis` signature.
## Architecture
```
┌──────────────┐
│ image bytes │
│ + image_base│
└──────┬───────┘
│
▼
xenia-cpu::iter_disasm(image, base, range)
│ yields DisasmItem
▼
xenia-analysis::enrich_section(...).map(|i| RichDisasmItem { i, section, function, label })
│ yields RichDisasmItem
▼
┌────────────────┼────────────────┐
▼ ▼ ▼
sinks::duckdb sinks::json sinks::text
append_instructions write_jsonl write_instr_line
│ │ │
▼ ▼ ▼
instructions .jsonl .asm
table (DuckDB) (one row/line) (formatted)
```
`DecodedInstr` (8 bytes, in decode cache) is unchanged. `DisasmItem` and `RichDisasmItem` only exist at the sink layer.
## Constraint #1 honored: DecodedInstr unchanged
Same as Phase 1 — `DecodedInstr` is still the 8-byte cache-resident struct; `DisasmItem` is allocated only in the iterator/sink layer.
## Verification
- `cargo build --workspace` clean (one previously-existing analysis warning was fixed during refactor).
- `cargo test -p xenia-cpu` — all 168 tests + 10 disasm tests pass (2 new for `iter_disasm`).
- `cargo test -p xenia-analysis` — all 9 audit tests pass.
- `xenia disasm <iso> -n 8` smoke test: same extended-mnemonic output as Phase 1.
- `xenia dis --db --json --quiet <iso>` end-to-end smoke test: PENDING (running at write time).
## LOC delta (Phase 2)
- xenia-cpu/src/disasm.rs: +60 (DisasmItem + iter_disasm + 2 tests)
- xenia-cpu/src/lib.rs: +1
- xenia-analysis/src/disasm.rs: +50 (new file)
- xenia-analysis/src/sinks/{mod,duckdb,json,text}.rs: +160 (new files)
- xenia-analysis/src/db.rs: −38 (collapsed loop)
- xenia-analysis/src/formatter.rs: −15 (annotate_branch deleted, inner loop replaced)
- xenia-analysis/Cargo.toml: +1 (serde_json dep)
- xenia-app/src/main.rs: +20 (--json flag + sink call)
- **Net: ~+240 LOC** (in line with the plan's "+250 / −250 net 0" estimate, modulo the new JSON sink which had no prior counterpart).
## Behavior changes visible to users
1. **New `xenia dis --json <path>` flag** — emits one structured JSON object per instruction. Schema: `addr, raw, mnemonic, operands, disasm, ext_mnemonic?, ext_operands?, ext_disasm?, branch_target?, section, function?, label?`.
2. Branch-target annotation in the .asm text output is now driven by the structured `branch_target` field (was a regex find of "0x" in the disasm string). Functionally equivalent for direct branches; immune to false-positive matches in non-branch operands containing hex.
3. Three sinks share one decode/format pass per instruction, but db+json+asm output runs decode 3 times (once per sink). Phase 7 / future work could fan out from a single iterator if needed.
## What's next (Phases 3-4)
Per [/home/fabi/.claude/plans/ok-execute-your-proposed-refactored-dolphin.md](plan):
- **Phase 3**: Split `db.rs` into `ingest_instructions` + `write_analysis_results`; add `target_hex BIGINT` column on `instructions`; add `crates/xenia-analysis/src/sql_views.rs` with `v_branch_xrefs`/`v_call_graph`/`v_reachability_from_entry`/`v_function_first_instruction`/`v_imports_called`; add `--analyze=rust|sql|both` flag (default `rust`). Rust passes (`func.rs`, `xref.rs`) stay default.
- **Phase 4**: Replace println-only audits with assert-based JSON-fixture goldens. Expand coverage to base + extended + VMX128 (silent-bug area) + DB schema + ISO-gated end-to-end.

78
migration/claude-memory/project_xenia_rs_disasm_unify_phase3.md Normal file
View File

@@ -0,0 +1,78 @@
---
name: Disassembler unification — Phase 3 complete (2026-04-27)
description: db.rs split into ingest_instructions + write_analysis_results; new sql_views.rs with 5 views; --analyze=rust|sql|both CLI flag; target_hex column on instructions; Rust/SQL cross-check warning in `both` mode.
type: project
originSessionId: 680cc54c-e77a-4d2d-a11b-ca562e9a68ec
---
**Phase 3 of disassembler unification is COMPLETE** (2026-04-27, same session).
## What's in place
### Schema
- **`instructions` table** gains a `target_hex BIGINT NULL` column populated from `DisasmText.branch_target`. Indexed via `idx_instructions_target_hex`. Documented in [crates/xenia-analysis/src/db.rs](crates/xenia-analysis/src/db.rs) module docstring.
- **DuckDB sink** ([crates/xenia-analysis/src/sinks/duckdb.rs](crates/xenia-analysis/src/sinks/duckdb.rs)) writes the new column.
### Split DbWriter API ([crates/xenia-analysis/src/db.rs](crates/xenia-analysis/src/db.rs))
- `pub fn ingest_instructions(pe, info, func_analysis, labels)` — creates `instructions` table + indices and streams rows via the iterator + duckdb sink. **No analysis tables.**
- `pub fn write_analysis_results(pe, info, func_analysis, labels, xrefs)` — creates `functions`, `labels`, `xrefs` tables + indices. Populated from Rust pass output.
- `pub fn write_disasm(...)` — back-compat wrapper that calls both. Existing callers (e.g. `cmd_exec`) keep working unchanged.
- `pub fn create_sql_views(&mut self)` — runs the SQL view definitions from `crate::sql_views::ALL_VIEWS`.
- `pub fn cross_check_branch_xrefs(&self) -> Result<(u64, u64)>` — returns `(sql_only, rust_only)` row counts for symmetric difference between `v_branch_xrefs` and `xrefs WHERE kind IN ('call','jump','branch')`.
### SQL views ([crates/xenia-analysis/src/sql_views.rs](crates/xenia-analysis/src/sql_views.rs)) — 5 views
- `v_branch_xrefs` — derived from `instructions.target_hex` self-join. CASE on mnemonic mirrors `xref.rs` kind logic: `bl`/`bla` → call, `b`/`ba` → jump, `bc*` → branch.
- `v_call_graph` — `xrefs ⨝ functions` filtered to `kind = 'call'`. Surfaces caller/callee names.
- `v_reachability_from_entry` — recursive CTE seeded from `labels.name = 'entry_point'`, transitive over `xrefs.kind IN ('call','jump','branch')`. `UNION` (not `UNION ALL`) handles call-graph cycles.
- `v_function_first_instruction` — `functions ⨝ instructions ON address`. Convenience for inspecting prologues.
- `v_imports_called` — `xrefs ⨝ labels` filtered to `xrefs.kind = 'call' AND labels.kind = 'import'`. Per-function import call summary.
All views are `CREATE OR REPLACE` — re-running is idempotent.
### CLI ([crates/xenia-app/src/main.rs](crates/xenia-app/src/main.rs))
- New `AnalyzeMode` enum (`Rust` / `Sql` / `Both`) derived `ValueEnum`.
- `Dis { ..., analyze: AnalyzeMode }` field with `default_value_t = AnalyzeMode::Rust`.
- `cmd_dis` routes through:
- Always: `write_base` → `ingest_instructions` → `write_analysis_results` (Rust passes always run, honoring constraint #3).
- `Sql` or `Both`: also `create_sql_views`.
- `Both`: also `cross_check_branch_xrefs` and log on disagreement (info if both zero, warn otherwise).
## Constraint #3 honored: Rust analysis stays default and functional
- Default flag value is `rust`.
- Rust passes (`func.rs` + `xref.rs`) ALWAYS run when `--db` is set. The `analyze` flag only controls whether SQL views are *additionally* created.
- The `xrefs` table is always populated by Rust passes. `v_branch_xrefs` is an alternative read surface, not a replacement.
- Data-ref pass (xref.rs lis+addi/ori register tracking) and function detection (func.rs prologue patterns) remain Rust-only — they are not cleanly relational.
## Verification
- `cargo build --workspace`: clean.
- `cargo test -p xenia-cpu` / `-p xenia-analysis`: all green (10 disasm tests + 9 audit + 168 cpu).
- `xenia dis --analyze=both --db <out>` smoke verified end-to-end: 1.87M instructions written, 299,615 with `target_hex` (16% — direct branches), all 5 views queryable, cross-check returns `(0, 0)` — Rust and SQL agree on every (source, target, kind) tuple.
- Sample reachability: 7,557 of 12,156 functions reachable from entry_point (62%) — sensible for a game with significant dead/unused code.
### Bugs found and fixed during verification
1. **Kind-tag mismatch.** `XrefKind::tag()` ([xref.rs:21-29](crates/xenia-analysis/src/xref.rs)) returns the SHORT tags `"call"` / `"j"` / `"br"` (and `"read"` / `"write"` / `"ref"`). The first version of `v_branch_xrefs` and `cross_check_branch_xrefs` used the LONG names (`'call'` / `'jump'` / `'branch'`) — which the comment in [db.rs](crates/xenia-analysis/src/db.rs) describes for the *trace* table, not `xrefs`. Cross-check returned 195K SQL-only rows. Fixed by changing CASE to `'call'` / `'j'` / `'br'`. **Don't trust the docstring at the top of db.rs** — `branch_trace.kind` uses long names but `xrefs.kind` uses short tags.
2. **Reachability view collapsed to 1 row.** First version seeded with `labels.address` (a single instruction VA) and looked for `xrefs.source = r.addr`. But the entry-point address (`mflr r12`) has no outgoing xref — branches happen at later instructions of the function. Fixed by reformulating as function-level reachability: seed with the function containing the entry_point label, then walk `function → instructions → xrefs → target's enclosing function`. `UNION` handles call-graph cycles.
## LOC delta (Phase 3)
- xenia-analysis/src/db.rs: +60 (split write_disasm; new methods)
- xenia-analysis/src/sql_views.rs: +120 (NEW)
- xenia-analysis/src/sinks/duckdb.rs: +1 line (target_hex column write)
- xenia-analysis/src/lib.rs: +1 line (mod sql_views)
- xenia-app/src/main.rs: +35 (AnalyzeMode enum + flag + routing + cross-check log)
- **Net: +217 LOC**.
## Behavior changes visible to users
1. **New `--analyze=rust|sql|both` flag on `xenia dis`**, default `rust`. Backward compatible — existing scripts behave the same.
2. **New `target_hex BIGINT` column on `instructions` table**. Existing queries work; new column adds query power for SQL-side branch xref derivation.
3. **5 SQL views** available when `--analyze` is `sql` or `both`. Read-only, idempotent.
4. **Cross-check warning** in `both` mode flags any drift between formatter mnemonic strings and `xref.rs` kind classification.
## What's next (Phase 4)
Per [/home/fabi/.claude/plans/ok-execute-your-proposed-refactored-dolphin.md](plan):
- **Phase 4**: Replace println-only audits with assert-based JSON-fixture goldens. Expand coverage to base + extended + VMX128 (silent-bug area) + DB schema golden + ISO-gated end-to-end consistency.

97
migration/claude-memory/project_xenia_rs_disasm_unify_phase4.md Normal file
View File

@@ -0,0 +1,97 @@
---
name: Disassembler unification — Phase 4 complete (2026-04-27)
description: Assert-based fixture goldens replace println-only audits. Three JSON snapshots locked, VMX128 silent-bug area covered by direct accessor unit tests + integration fixture, DB schema golden enforces 7-table column layout + 5 SQL views.
type: project
originSessionId: 680cc54c-e77a-4d2d-a11b-ca562e9a68ec
---
**Phase 4 of disassembler unification is COMPLETE** (2026-04-27, same session).
## What's in place
### Fixture-based goldens for the disassembler
- **[crates/xenia-cpu/tests/disasm_goldens.rs](crates/xenia-cpu/tests/disasm_goldens.rs)** (~280 LOC) — three tests, each loads a JSON fixture and asserts every field of `xenia_cpu::disasm::format(decode(raw, addr))` matches.
- `tests/golden/base_mnemonics.json` — 77 cases covering common ALU / load-store / branch / compare / FPU forms.
- `tests/golden/extended_mnemonics.json` — 51 cases covering the simplified-mnemonic priority order (`li`, `lis`, `subi`, `mr`, `not`, `nop`, `slwi`, `srwi`, `clrlwi`, `clrrwi`, `extlwi`, `clrldi`, `srdi`, `rotldi`, `cmpwi`, `cmpdi`, `cmplwi`, `blr`, `blrl`, `bctr`, `bctrl`, `beqlr`, `bnelr`, `beq`, `bne`, `blt`, `bge`, `bgt`, `ble`, `bdnz`, `bdz`, `b` from `bc 20`, `mflr`, `mfctr`, `mfxer`, `mtlr`, `mtctr`, `mtxer`, `crnot`, `crclr`, `crset`, `crmove`, `lwsync`, `trap`, `tdeqi`, `twlti`).
- `tests/golden/vmx128_registers.json` — 16 cases covering standard VMX (5-bit regs) and the silent-bug VMX128 op6 vd128 high-bit area (vd128 = 96, 127 with vrlimi128; lower-bit encodings record what they actually decode to since the op6 secondary key constrains bits 21-23).
- **Regen workflow**: `REGEN_GOLDENS=1 cargo test -p xenia-cpu --test disasm_goldens` overwrites all three fixtures from current `format()` output. First run also auto-creates if the file is missing (with a panic afterwards forcing the developer to inspect+commit).
- **xenia-cpu Cargo.toml** gains `serde` + `serde_json` as `dev-dependencies` only — production lib stays serde-free, honoring constraint #1.
### VMX128 silent-bug area: direct accessor unit tests
- **[crates/xenia-cpu/src/decoder.rs](crates/xenia-cpu/src/decoder.rs)** has 7 new unit tests in the existing `tests` module that pin the canonical bit positions for `va128`/`vb128`/`vd128`/`vs128`:
- `vmx128_vd128_low_5_bits_only` — 32 iterations covering vd_lo = 0..31 with vd_b21 = vd_b22 = 0.
- `vmx128_vd128_bit21_adds_32` — bit 21 = 1 produces vd128 = 32.
- `vmx128_vd128_bit22_adds_64` — bit 22 = 1 produces vd128 = 64.
- `vmx128_vd128_full_127` — vd_lo = 31 + bit 21 + bit 22 = 127.
- `vmx128_va128_uses_bit29` — va128 = bits 6-10 + bit 29.
- `vmx128_vb128_uses_bits28_and_30` — vb128 = bits 16-20 + bit 28 + bit 30.
- `vmx128_vs128_aliases_vd128` — vs128 ≡ vd128 across {0, 31, 32, 64, 96, 127}.
- These pin decoder.rs as the canonical source. The pre-Phase-1 ppc.rs had different (wrong) positions; this test set guarantees the bug never returns silently.
### Analysis-side goldens (shim parity)
- **[crates/xenia-analysis/tests/disasm_goldens.rs](crates/xenia-analysis/tests/disasm_goldens.rs)** (~120 LOC) — 4 tests that load the *same* cpu-side fixture JSON files (via `..` relative path) and verify:
- `xenia_analysis::ppc::disasm(raw, addr).base` == `xenia_cpu::disasm::format(...).disasm`
- `.ext` == `format().ext_disasm`
- All structured fields (`mnemonic`/`operands`/`ext_*`/`branch_target`) match the fixture row.
- `display()` returns extended form when present, base otherwise.
- The cpu fixtures are the single source of truth; analysis shim drift surfaces immediately.
### DB schema golden
- **[crates/xenia-analysis/tests/db_schema_golden.rs](crates/xenia-analysis/tests/db_schema_golden.rs)** (~230 LOC) — one test that builds an in-memory 16-byte PE-shaped fixture (4 instructions: mflr / nop / blr / nop), runs the full `DbWriter` pipeline (`write_base` → `ingest_instructions` → `write_analysis_results` → `create_sql_views`), and asserts:
- Every column name + type for all 7 tables (`metadata`, `sections`, `imports`, `instructions`, `functions`, `labels`, `xrefs`) via `PRAGMA table_info`.
- Row counts (4 instructions, 0 with target_hex since the fixture is indirect-only).
- All 5 SQL views (`v_branch_xrefs`, `v_call_graph`, `v_function_first_instruction`, `v_imports_called`, `v_reachability_from_entry`) exist after `create_sql_views`.
- Schema drift caught immediately.
- **Caveat noted in comments**: SQL `LIKE 'v_%'` matches DuckDB's built-in `views` system view because `_` is a single-char wildcard. The test enumerates view names explicitly.
### Deletions
- **xenia-cpu/tests/disasm_audit.rs** (161 LOC) — println-only, no assertions. Migrated to the assert-based goldens above.
- **xenia-analysis/tests/disasm_audit.rs** (164 LOC) — same.
## Verification
`cargo test --workspace`: 29 test groups, 0 failures. All previously-passing tests still pass (176 cpu interpreter + 13 disasm + 7 VMX128 accessors + 4 analysis goldens + 1 schema golden + everything else).
```
$ cargo test --workspace 2>&1 | grep -c "test result: ok"
29
$ cargo test --workspace 2>&1 | grep -c "FAILED\|failed"
0
```
## Discoveries / fixture-author surprises
1. **VMX128 op6 vrlimi128 vd128 < 96 is not a valid encoding.** The secondary key uses bits 21-23 = 111, so the high two bits of vd128 (which share bits 21+22) MUST be 11 for the dispatch to land on vrlimi128. Lower-bit attempts decode as vsrw128 / vpermwi128 instead. The fixture records this exact behavior — labeled honestly so future readers don't think these cases test what they don't.
2. **Sylpheed's real corpus only contains vrlimi128 with vd128 ∈ 96..=127** (consistent with the constraint above). The decoder has been emitting these correctly since Phase 1's silent-bug fix; the goldens now lock that behavior.
3. **`PRAGMA table_info` doesn't accept bind parameters** in DuckDB the way `WHERE` does — it uses the statement-level interpolation route. Inlined the table name into the query string with simple format!.
4. **DuckDB has a built-in `views` system view** that matches SQL `LIKE 'v_%'` (because `_` is a single-char wildcard, `views` = `v` + 'i' + 'ews' fits). Always enumerate view names explicitly, or use `LIKE 'v\_%' ESCAPE '\'`.
## LOC delta (Phase 4)
- xenia-cpu/tests/disasm_goldens.rs: +388 (new)
- xenia-cpu/tests/golden/*.json: +28k bytes (~700 lines committed JSON across 3 files)
- xenia-cpu/src/decoder.rs: +95 (7 new VMX128 accessor unit tests)
- xenia-cpu/Cargo.toml: +4 (dev-dependencies serde+serde_json)
- xenia-cpu/tests/disasm_audit.rs: −161 (deleted)
- xenia-analysis/tests/disasm_goldens.rs: +120 (new)
- xenia-analysis/tests/db_schema_golden.rs: +245 (new)
- xenia-analysis/tests/disasm_audit.rs: −164 (deleted)
- **Net: +527 LOC test code + ~700 lines JSON fixtures, −325 LOC of useless println audits.**
## Tooling for future authors
- **Adding new test cases**: edit `cases: &[(u32, u32, &str)]` array inline in `tests/disasm_goldens.rs`, run `REGEN_GOLDENS=1 cargo test -p xenia-cpu --test disasm_goldens`, inspect the diff in the JSON fixture, commit.
- **Detecting drift**: any change to `format()` output that affects existing cases will fail the assertion test, naming the row label and showing the diff. Either the change is intentional (regen) or it's a regression (fix code).
- **Schema changes**: `db_schema_golden.rs` will fail if you add/remove/rename a column or change a type. Update the `expected` slice in the test.
## End-of-phase status
All four phases of the disassembler unification are now complete:
- **Phase 1**: single-source-of-truth `format()` in xenia-cpu; analysis ppc.rs collapsed to a 30-line shim; VMX128 silent bug fixed.
- **Phase 2**: iterator + 3 sinks (text/JSON/DuckDB) layer; `--json` CLI flag.
- **Phase 3**: db.rs split into ingest/analyze; 5 additive SQL views; `--analyze=rust|sql|both` flag with cross-check warning.
- **Phase 4**: assert-based fixture goldens + VMX128 accessor unit tests + DB schema golden replacing the println-only audits.
The `DecodedInstr` struct stays at 8 bytes throughout; the decode cache stays at 1.3 MiB; Rust analysis (`func.rs`, `xref.rs`) remains the default and is unchanged. All three user constraints honored end-to-end.

12
migration/claude-memory/project_xenia_rs_duckdb.md Normal file
View File

@@ -0,0 +1,12 @@
---
name: xenia-rs analysis DB is DuckDB, not SQLite
description: Reminder that xenia-analysis switched from rusqlite to duckdb — the `.db` extension is misleading
type: project
originSessionId: f35a2810-e5b7-46ac-a4d9-ea87304be179
---
**Why:** Historical — files named like `sylpheed.db` still use the legacy extension, but the file format is DuckDB (verified via `file sylpheed.db → "DuckDB database file, version 64"`). `xenia-analysis/Cargo.toml` depends on `duckdb = { workspace = true }`; there is no `rusqlite`. The CLI memory's mention of "SQLite DB" is stale.
**How to apply:**
- CLI `sqlite3 path.db` will not open it; use `python3 -c "import duckdb; con = duckdb.connect('path.db', read_only=True); ..."` or install the `duckdb` CLI.
- Schema matches what the CLI memory describes (functions/imports/instructions/labels/metadata/sections/xrefs), just with DuckDB's SQL dialect. `SHOW TABLES` works; `SELECT name FROM sqlite_master` also works for compat.
- When querying, prefer Python with `read_only=True` so you don't step on concurrent writers.

61
migration/claude-memory/project_xenia_rs_edram_resolve_gap.md Normal file
View File

@@ -0,0 +1,61 @@
---
name: EDRAM→memory resolve byte copy — status and remaining gaps
description: What now ships on TILE_FLUSH, which paths still fall through to skip/warn, and the Canary anchors for future expansion
type: project
originSessionId: c0486ac0-d44e-49fc-8a8d-6c28cb11ab9d
---
## Status (post 2026-04-22 landing)
`handle_event_initiator` at [gpu_system.rs:376+](../../../../xenia-rs/crates/xenia-gpu/src/gpu_system.rs)
now **writes bytes into guest memory** on TILE_FLUSH. End-to-end flow:
1. `ResolveInfo::from_register_file` ([draw_state.rs](../../../../xenia-rs/crates/xenia-gpu/src/draw_state.rs)) decodes `RB_COPY_CONTROL / RB_COPY_DEST_*` + `RB_SURFACE_INFO / RB_COLOR_INFO_* / RB_DEPTH_INFO / RB_COLOR_CLEAR / RB_COLOR_CLEAR_LO / RB_DEPTH_CLEAR` into a full Canary-parity struct: rectangle (scissor ∩ dest_pitch, 8-pixel aligned), source base tiles, surface_pitch_tiles (via `GetSurfacePitchTiles`), MSAA, 64bpp flag, clear values, dest_base **masked to `0x1FFF_FFFF`**, Endian128, format, array flag.
2. `ShadowEdram` ([edram.rs](../../../../xenia-rs/crates/xenia-gpu/src/edram.rs)) — 10 MiB (2048 × 80 × 16 samples × 4 B) CPU-side EDRAM that holds per-tile bytes. Clear-resolves paint `RB_COLOR_CLEAR` into the source tiles via `fill_rect_32bpp`; the copy loop reads out via `read_sample_32bpp`.
3. `resolve::copy_to_memory` ([resolve.rs](../../../../xenia-rs/crates/xenia-gpu/src/resolve.rs)) — per-pixel loop. For `k_8_8_8_8` source + dest (bitwise-equivalent fast path) it applies `apply_endian_128` and calls `mem.write_u32(tiled_2d_offset(x, y, pitch_aligned_to_32, bpp_log2=2))` — page versions bump so `texture_cache_host.rs` re-uploads on next bind.
4. `stats.resolves_copied_total` + `resolves_skipped_total` + `resolve_samples_written` flow to the HUD row 2.
## What's supported (expanded coverage)
- **Color sources** (any of these → any compatible color dest):
- `k_8_8_8_8` (0), `k_8_8_8_8_GAMMA` (1) → `k_8_8_8_8` (6), `k_8_8_8_8_A` (14), `k_8_8_8_8_AS_16_16_16_16` (50).
- `k_2_10_10_10` (2), `k_2_10_10_10_AS_10_10_10_10` (10) → `k_2_10_10_10` (7), `k_2_10_10_10_AS_16_16_16_16` (54).
- `k_16_16_FLOAT` (6) → `k_16_16_FLOAT` (31).
- `k_32_FLOAT` (14) → `k_32_FLOAT` (36).
- Gated by `is_32bpp_bitwise_equivalent` ([resolve.rs](../../../../xenia-rs/crates/xenia-gpu/src/resolve.rs)) mirroring Canary `IsColorResolveFormatBitwiseEquivalent` (xenos.h:614).
- **Depth sources**: `kD24S8` (0) → `k_24_8` (22); `kD24FS8` (1) → `k_24_8_FLOAT` (23). Reads depth tiles at `RB_DEPTH_INFO.depth_base`.
- **Rectangle derivation**: vertex-fetch-constant-0 when present (6-dword vertex buffer with endian-decoded floats, Fixed16p8 rounding, 3-vertex bounding box per Canary `draw_util.cc:950-1028`). Falls back to scissor ∩ `(0, 0, dest_pitch, dest_height)` when VF0 isn't a valid resolve vertex buffer. All outputs 8-pixel-aligned via `RESOLVE_ALIGNMENT_PIXELS = 8`.
- **`CopySampleSelect` sanitation** (`xenos.h:1039-1052`): MSAA + depth remap invalid selectors. Single-sample picks (`k0/k1/k2/k3`) honored; averaging modes (`k01/k23/k0123`) pick sample 0 + log `warn` (full averaging TODO).
- Endian: `kNone`, `k8in16`, `k8in32`, `k16in32` all correct. `k8in64`/`k8in128` approximated as `k8in32` + `tracing::warn`.
- Clear-resolve + copy-resolve paths both work.
- Destination address masked to Xenon 29-bit physical space.
## What logs + skips (graceful)
All of the below return `resolves_skipped_total += 1` with a `tracing::warn` identifying the reason — boot continues:
- 64bpp source (`k_16_16_16_16`, `k_16_16_16_16_FLOAT`, `k_32_32_FLOAT`).
- 3D/stacked destination (`copy_dest_array = 1`) — Canary `Tiled3D` not ported.
- Non-zero `dest_exp_bias` on linear formats.
- Non-bitwise-equivalent source/dest pair (e.g. `k_16_16` → `k_16_16`, which would need conversion tables).
## Deferred (next-session backlog, ordered by ROI)
**Small, bounded — take these first:**
1. **MSAA sample averaging** (`CopySampleSelect::k01/k23/k0123`). Today falls back to sample 0 + `warn`. Fix: read N samples, average by format-aware rule (unorm8 averaged as int, float averaged as float). Needs per-format decoder.
2. **64bpp source** (`k_16_16_16_16`, `k_16_16_16_16_FLOAT`, `k_32_32_FLOAT`). Skipped + logged. Needs double-tile EDRAM stride (`pitch_tiles << is_64bpp`) and two `write_u32` per pixel. Straightforward refactor of `resolve::copy_to_memory`.
3. **`RB_COLOR_CLEAR_LO` for 64bpp clear paint**. Already captured in `ResolveInfo` but `fill_rect_32bpp` only writes one lane. Companion to #2.
4. **Endian `k8in64` / `k8in128`** (properly). Approximated as `k8in32` today. Buffer pixels in pairs/quads before tile-write. Rare in practice.
5. **`copy_dest_exp_bias != 0`**. Skipped + logged. Needs float-format awareness; bake the scale factor into the sample converter.
**Large lifts — their own sessions:**
6. **wgpu render-target readback into `ShadowEdram`**. The clear-then-resolve path works, but once Sylpheed *draws* (currently `first Xenos draw: 0`), drawn pixels never reach EDRAM because the draw pipeline writes to wgpu attachments, not the shadow. Needs async `copy_texture_to_buffer` + CPU retile. Probably what unblocks frame-2 and beyond.
7. **3D / array destinations** (`copy_dest_array = 1`). Needs Canary's `Tiled3D` + `GetTiledOffset3D` ported. Rare on first-pixels path.
8. **Non-bitwise-equivalent conversion** — e.g. `k_16_16` RT (signed, range [-32, 32]) → `k_16_16` texture (unsigned). Requires Canary's conversion shader tables (`draw_util.cc:1320-1391` shader selection).
## Canary anchors (for future expansion)
- [draw_util.cc:926-1318](../../../../xenia-canary/src/xenia/gpu/draw_util.cc) — full `GetResolveInfo` including vertex-fetch rect.
- [draw_util.cc:1320-1391](../../../../xenia-canary/src/xenia/gpu/draw_util.cc) — shader selection (fast vs full paths).
- [render_target_cache.cc:1045](../../../../xenia-canary/src/xenia/gpu/render_target_cache.cc) — `GetResolveCopyRectanglesToDump` for host-RT dump.
- [texture_address.h:190-260](../../../../xenia-canary/src/xenia/gpu/texture_address.h) — `Tiled3D` (for copy_dest_array).
- [xenos.h:1039-1047](../../../../xenia-canary/src/xenia/gpu/xenos.h) — `SanitizeCopySampleSelect` for the MSAA sample-select rules.

116
migration/claude-memory/project_xenia_rs_fix_session_2026_05_03.md Normal file
View File

@@ -0,0 +1,116 @@
---
name: xenia-rs audit-2026-05 fix-session outcome (2026-05-03)
description: Single-session sprint applied 11 commits closing 12 audit IDs across 4 of the 8 planned phases. Renderer plateau partially unblocked but draws=0 persists; parked-waiter handles unresolved. Next session should target the producer side of those handles directly.
type: project
originSessionId: d3aef0c2-0968-4c35-a482-197640977756
---
## Headline outcome
Single-session fix sprint executed against the audit-2026-05 fix queue.
Plan: `/home/fabi/.claude/plans/we-just-finished-a-shiny-conway.md`.
**12 P0/P1 IDs closed, 11 commits, 9 merge commits on master**:
Phase A: SWAPBUG-001 / PPCBUG-001 (P0 — addi 32-bit truncation revert)
Phase B: ORACBUG-004 (P0 — sylpheed_n50m stable-digest oracle)
Phase C: KRNBUG-Vd-04, GPUBUG-001, XMODBUG-013 (3× P0 — VdSwap PM4 ring path)
Phase D1: GPUBUG-101 (P0 — c-vs-temp src selector at w0[29:31])
Phase D2: GPUBUG-100 (P0 — operand swizzle + negate from w1, abs deferred)
Phase D3: GPUBUG-102 (P0 — vertex-fetch endian byte-swap)
Phase E: GPUBUG-103/104/105 (3× P0 — 8 register addresses + index_size bit)
Phase F1: KRNBUG-017 (P0-under-parallel — Kf*SpinLock real impl)
Phase G1: GPUBUG-006 (P1 — sync_with_mmio Acquire/Release)
Phase G2: XMODBUG-002 (P1 — write_bulk page_version bump)
## What moved
- `swaps` at -n 100M lockstep: **1 → 2** (Phase A; the audit's bisected swap regression closed).
- `instructions=100M` deterministic; `imports` 11.4M → 987k (game escaped the corrupted-address retry loop).
- Workspace tests: **551 → 556** (+5 net).
- Lockstep stable-fields determinism preserved across all phases (only `packets` varies, ±5%).
## What did NOT move
- **`draws=0` persists at -n 100M lockstep.** The audit's central prediction
("Phases C+D+E together unlock draws > 0") was not met. Root cause: the renderer
plateau is multi-causal, and within 100M instructions the game stalls on
parked-waiter handles BEFORE reaching draw issue.
- `shader_blobs_live=0` after 100M — the game hasn't issued IM_LOAD; resource-loader
worker threads are still parked (handles 0x1004 / 0x100c / 0x15e4 / 0x42450b5c
per `project_xenia_rs_audit_2026_05_02.md`).
## Architectural notes & gotchas
- **VdSwap PM4 path (Phase C)**: empirically discovered that `buffer_ptr` (r3 to
VdSwap) is NOT in the primary ring on xenia-rs (canary's contract says it is).
Real test:
`buffer_ptr=0x4acd4df8`, `ring_base=0x0accb000`, `size=0x1000` (4 KB ring).
Workaround landed: cache ring_base/size on `KernelState` at
VdInitializeRingBuffer time, then write PM4 packets at the actual ring WPTR
inside vd_swap. The original `notify_xe_swap` direct-call is retained as a
safety-net fallback, gated on `swaps_seen` not advancing during the drain.
- **Phase D1 redo**: the audit memo's "bit 7 of src byte = c#-vs-r# selector"
was wrong — bit 7 is the `is_src_temp_value_absolute` flag. Canary's actual
selector lives at word-0 bits 29-31 (`src1_sel`/`src2_sel`/`src3_sel` per
`xenia-canary/src/xenia/gpu/ucode.h:2078-2086`). First D1 commit was
reset+redone with correct decoding.
- **Phase G3 not landed**: the Plan agent claimed canary writes back addic/
addicx/subficx as `i32 → i64 → u64` (sign-extended). Direct verification at
`xenia-canary/src/xenia/cpu/ppc/ppc_emit_alu.cc:117-136` shows canary uses
**full 64-bit add with sign-extended immediate, no truncation**. Reverting
the 32-bit ABI workaround risks regressions (Sylpheed PPC code may have
polluted upper-32-bit values that the workaround currently masks). Defer
until canary semantics are confirmed against a known-good Sylpheed trace.
## Engineering decisions worth remembering
- **`--stable-digest` flag** (xenia-app/main.rs): a new `RunDigest::stable_fields_json()`
view excludes timing-sensitive fields (`packets`, `interrupts_delivered`,
`interrupts_dropped`, `resolves`, `texture_decodes`) and `path` (cwd-dependent).
Required because empirical determinism check showed `packets` varies ±5-8%
between two consecutive lockstep runs at -n 50M (GPU thread race per audit M11).
All future lockstep goldens for -n ≥50M MUST use this flag.
- **n4b canonical-invocation oracle deferred**: per audit memory,
`--parallel --reservations-table` is "pathologically slow >32 min for -n 100M".
At -n 4B that's many hours per run, not the 5-15 min the original plan
estimated. Capture as a one-shot artifact under `audit-runs/post-fix/`
(NOT a test golden) once `draws > 0` lands.
- **`KernelState.ring_base` / `ring_size_dwords` fields**: cached at
VdInitializeRingBuffer time so `vd_swap` can write PM4 packets directly into
ring memory without a channel hop to the GPU worker (which would otherwise
own the ring view in threaded mode). Pattern for similar "kernel needs to
know GPU layout" cases.
## Next session — recommended starting point
1. **Trace parked-waiter producers.** Run `xenia-rs check sylpheed.iso -n 4B
--trace-handles` and look for: which kernel-side function is supposed to
signal handle 0x1004 / 0x100c / 0x15e4 / 0x42450b5c? The audit ruled out
XamTaskSchedule (XAMBUG-001) as the cause; the actual producer is in the
guest code-path leading up to where workers park. Walk back from the park
site (per `project_xenia_rs_sylpheed_stage3_2026_04_29.md`).
2. **Phase G2 (VSYNC wall-clock) + n2m oracle re-baseline as a paired commit**.
3. **Phase F2/F3** (XamTaskSchedule callback spawn + overlapped completion
helper) if appetite for new XAM infrastructure.
4. **KRNBUG-Mm cluster** for proper Mm protect / range / per-heap honoring.
Required before re-evaluating the addic/subfic semantics.
## Build state at sprint close
- HEAD master: `6f851a2` (will be `<H-merge-sha>` after the close-out merge).
- Tests: 556 passing (up from 551 baseline).
- Workspace clean except `audit-runs/post-fix/` and `sylpheed.db.apr18.bak`
(both untracked, audit artifacts).
- audit-findings.md updated with "Fix session 2026-05-03" close-out section
documenting all closed IDs, deferred IDs (with reasons), and recommended
next session.
- All sprint branches deleted post-merge.
## Cross-references
- Builds on: `project_xenia_rs_audit_2026_05_02.md` (the audit this session
consumed).
- Builds on: `project_xenia_rs_addis_signext_root_cause_2026_04_29.md` (the
addis 32-bit truncation pattern; SWAPBUG-001 was an over-extension to addi).
- Builds on: `project_xenia_rs_sylpheed_stage3_2026_04_29.md` (parked-waiter
4-handle map; still unresolved at this sprint's close).

63
migration/claude-memory/project_xenia_rs_handle_audit.md Normal file
View File

@@ -0,0 +1,63 @@
---
name: xenia-rs handle-audit harness + post-2026-04-25 sync state
description: Per-handle signal/wait/wake audit (—trace-handles), and the diagnostic finding that the previously-reported HLE sync gap no longer reproduces at -n 500M
type: project
originSessionId: f83e67b7-97f4-4222-a37f-e1720ab3ace6
---
## Audit harness landed
[`xenia-kernel/src/audit.rs`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-kernel/src/audit.rs) — `HandleAudit` + `HandleAuditTrail` capture create/signal/wait/wake events per kernel handle, bounded ring of 32 entries each. `KernelState::audit` is `enabled=false` by default; flip via `--trace-handles` flag or `XENIA_TRACE_HANDLES=1`. Disabled is a single inline early-return in each record method — zero hot-path cost.
Hook sites (in [`xenia-kernel/src/exports.rs`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-kernel/src/exports.rs)):
- **Create**: `nt_create_event`, `nt_create_semaphore`, `nt_create_timer`
- **Signal**: `KeSetEvent`, `NtSetEvent`, `KePulseEvent`, `NtPulseEvent`, `KeReleaseSemaphore`, `NtReleaseSemaphore`, `NtSignalAndWaitForSingleObjectEx` (signal half), `signal_io_completion_event`
- **Wait**: `do_wait_single`, `do_wait_multiple` (one record per handle in the wait set)
- **Wake**: inside `wake_eligible_waiters` (separate records for manual-reset fan-out vs auto-reset/semaphore single-wake)
Diagnostic dump in [`xenia-app/src/main.rs::dump_thread_diagnostic`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-app/src/main.rs) prints the audit trail at end-of-run when audit is enabled. Highlights `<NO_SIGNALS_DESPITE_WAITS>` (smoking gun for missing signal source) and `<SUSPECT>` (handles called out in the original deadlock report).
## Diagnostic finding (2026-04-25)
The HLE sync gap previously reported at ~7.5M cycles on Sylpheed boot is **no longer reproducing**. Verified:
- `xenia-rs exec sylpheed.iso --halt-on-deadlock -n 500_000_000` — `EXIT=0`, no halt fired, no `scheduler.deadlock_halts` or `scheduler.deadlock_recoveries` counters appear.
- VdSwap=1 fires at ~22M instructions, VdSwap=2 at ~30M instructions; matches the post-Tier-4 baseline.
- Audit data confirms the originally-suspect handles (0x10FC, 0x1014, 0x1104, 0x10DC, 0x10F0) all *do* receive signals: e.g., 0x10FC = Event/Auto with 1 signal (NtSetEvent from tid=4) + 1 wake; 0x1014 = Semaphore with 15 signals / 15 wakes / 16 waits.
- Threads still parked at end-of-run (tids 2/3/4/5/6/10/13/14/16/18) are in normal worker-idle states (event+semaphore producer/consumer with timeouts, or "service exits on stop-event" with no shutdown signal — both expected).
**Why:** likely a combination of the IRQ-injection stack-pad fix (2026-04-24) and Tier-4 perf work (2026-04-25) shifted scheduler timing past the previous deadlock window.
**How to apply:** APC + Mutant infrastructure (`KeInitializeApc=0x6D`, `KeInsertQueueApc=0x7A`, `NtQueueApcThread=0xE3`, `KeAlertThread=0x4F`, `KeInitializeMutant=0x72`, `KeReleaseMutant=0x87`, `NtCreateMutant=0xD4`, `NtReleaseMutant=0xF2` — all in canary [`xboxkrnl_threading.cc`](../../../RE%20Project%20Sylpheed/xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_threading.cc)) was planned but DEFERRED — the audit data did not point to a missing kernel API. Implement only when a future regression actually requires it.
## Resolve fill-ins landed (2026-04-25)
[`xenia-gpu/src/edram.rs`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-gpu/src/edram.rs) gained: `write_sample_32bpp`, `write_rect_32bpp`, `read_sample_64bpp`, `write_sample_64bpp`, `write_rect_64bpp`, `fill_rect_64bpp`. 64bpp helpers use Canary's doubled-pitch convention (`pitch_tiles_32bpp << 1`).
[`xenia-gpu/src/resolve.rs`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-gpu/src/resolve.rs) `copy_to_memory` now handles:
1. **64bpp sources** via new `is_64bpp_bitwise_equivalent` (k_16_16_16_16, k_16_16_16_16_FLOAT, k_32_32_FLOAT). Two `write_u32` per pixel; `bpp_log2 = 3` for tiled offset.
2. **MSAA averaging** (k01/k23/k0123) via per-format decode/average/encode helpers:
- `k_8_8_8_8`/`k_8_8_8_8_GAMMA`: per-byte rounded unsigned mean
- `k_2_10_10_10`: per-field rounded mean (widths 2/10/10/10)
- `k_16_16_FLOAT`, `k_16_16_16_16_FLOAT`: half-float decode → fp32 sum → encode
- `k_32_FLOAT`, `k_32_32_FLOAT`: bitcast → fp32 sum → bitcast
- `k_16_16_16_16`: per-16-bit-field rounded mean
[`xenia-gpu/src/gpu_system.rs`](../../../RE%20Project%20Sylpheed/xenia-rs/crates/xenia-gpu/src/gpu_system.rs) clear-paint dispatches to `fill_rect_64bpp` for 64bpp sources, using `RB_COLOR_CLEAR_LO` (lo) + `RB_COLOR_CLEAR` (hi) per Canary `draw_util.cc:1302-1303`.
Endian k8in64/k8in128 and `copy_dest_exp_bias != 0` remain on backlog (rare on first-pixels path); current code preserves the pre-existing warn+skip behavior for both.
## wgpu→ShadowEdram readback — deferred, foundation in place
`ShadowEdram` write APIs (`write_rect_32bpp`, `write_rect_64bpp`) are the foundational data-structure work the future readback retile path will use. The cross-thread plumbing (UiBridge `request_rt_readback` / `poll_rt_readback`, per-RT offscreen wgpu textures in `xenos_pipeline.rs`, `copy_texture_to_buffer` + `map_async` callback) is **deferred**: Sylpheed's current boot path fires no Xenos draws, so wiring the cross-thread readback today would land speculative code that can't be exercised against a real game flow. The plan file at [`/home/fabi/.claude/plans/please-address-the-hle-eager-pixel.md`](../../../home/fabi/.claude/plans/please-address-the-hle-eager-pixel.md) Section 2 has the full design (`ReadbackState`, `OffscreenRt`, `RtCache`).
## Verification (2026-04-25 session)
- `cargo test --workspace --release` — **386 tests pass** (was 369 baseline; +17 new for audit, edram, resolve).
- `xenia-rs check sylpheed.iso -n 2_000_000 --expect crates/xenia-app/tests/golden/sylpheed_n2m.json` — clean in both default block-cache mode and `XENIA_FORCE_PER_INSTR=1` per-instruction mode.
- `xenia-rs exec sylpheed.iso --halt-on-deadlock -n 500_000_000` — `EXIT=0`, no deadlock counters tripped.
- `cargo bench -p xenia-cpu` — `tight_alu_loop=119.86 MIPS`, `loadstore_loop=95.67 MIPS`, `mmio_storm=70.08 MIPS` (all at or above the prior post-Tier-4 baseline of 114.8 / 91.8 / 67.8).
## Files touched this session
- New: `xenia-rs/crates/xenia-kernel/src/audit.rs`.
- Modified: `xenia-kernel/src/lib.rs` (mod), `state.rs` (KernelState::audit + helpers), `exports.rs` (hook calls at create/signal/wait/wake sites). `xenia-app/src/main.rs` (--trace-handles flag, audit dump in dump_thread_diagnostic, env var `XENIA_TRACE_HANDLES`). `xenia-gpu/src/edram.rs` (new 32bpp+64bpp write APIs + fill_rect_64bpp + tests). `xenia-gpu/src/resolve.rs` (is_64bpp_bitwise_equivalent + 64bpp source path + MSAA averaging + half-float helpers + tests). `xenia-gpu/src/gpu_system.rs` (64bpp clear-paint dispatch).

37
migration/claude-memory/project_xenia_rs_hle_import_fixes_2026_04_27.md Normal file
View File

@@ -0,0 +1,37 @@
---
name: HLE import fixes (2026-04-27)
description: Three real bugs from the kernel-import audit fixed — KeInitializeSemaphore seeds count/limit, XexGet{Module,Procedure}Address use distinct pseudo-handles + reverse thunk map.
type: project
originSessionId: e11f9c65-ab38-4eac-bff2-c5a64c5b8467
---
## What changed (2026-04-27)
Fixed the three ❌ findings from the kernel/HLE/imports audit. All three Sylpheed-imported and previously latent.
1. **KeInitializeSemaphore** ([exports.rs:498](xenia-rs/crates/xenia-kernel/src/exports.rs#L498)) — was a 0x14-byte zero-fill that dropped r4 (count) and r5 (limit). `ensure_dispatcher_object` later read those-now-zero fields and minted `Semaphore { count: 0, max: 1 }`. Now writes proper DISPATCHER_HEADER + signal_state(+0x4) + limit(+0x10) per [canary xboxkrnl_threading.cc:692](xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_threading.cc#L692).
2. **XexGetProcedureAddress** ([exports.rs:2366](xenia-rs/crates/xenia-kernel/src/exports.rs#L2366)) — was a stub returning STATUS_OBJECT_NAME_NOT_FOUND unconditionally, ignoring r3 (hmodule). Now resolves r3→ModuleId, looks up (module, ordinal) in a new reverse thunk map, writes the address to *r5, returns STATUS_SUCCESS / STATUS_INVALID_HANDLE / STATUS_OBJECT_NAME_NOT_FOUND.
3. **XexGetModuleHandle** ([exports.rs:3231](xenia-rs/crates/xenia-kernel/src/exports.rs#L3231)) — was returning `state.image_base` for `"xboxkrnl.exe"` (wrong — that's the game's image) and `0` for `"xam.xex"`. Also wrong calling convention (handle in r3 vs canary's NTSTATUS-in-r3-and-handle-via-*r4). Now uses distinct pseudo-handles `HMODULE_XBOXKRNL=0xFFFE_0001` / `HMODULE_XAM=0xFFFE_0002`, writes to *r4, returns NTSTATUS in r3 (X_ERROR_NOT_FOUND=0x048B for unknown).
## New plumbing
- `pub const HMODULE_XBOXKRNL`, `HMODULE_XAM` in [state.rs:42-50](xenia-rs/crates/xenia-kernel/src/state.rs#L42).
- `KernelState.thunks_by_ordinal: HashMap<(ModuleId, u16), u32>` field; helpers `register_thunk`, `resolve_thunk`, `module_id_from_hmodule`.
- main.rs Phase 1 thunk loop now also pushes into `thunk_addr_map: Vec<(ModuleId, u16, u32)>` and drains it into `kernel.register_thunk(...)` right after `KernelState::with_gpu(...)` ([main.rs:737](xenia-rs/crates/xenia-app/src/main.rs#L737)).
## Verification
- `cargo test -p xenia-kernel` → 76/76 (was 73; 3 new tests added).
- `cargo test --workspace` → all green.
- `xenia-rs check sylpheed.iso -n 30M --parallel` → instructions=30M, swaps=2, unimpl=0, interrupts=53. **VdSwap=2 baseline preserved.**
## Files touched
- [xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs)
- [xenia-kernel/src/exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs) (rewrote 3 export bodies + 1 new const + 3 tests near line 4818)
- [xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) (lines 633-651 + 737-742)
## Why this matters
Sylpheed only calls `KeInitializeSemaphore` once during boot (visible in the digest) and so far hasn't tripped over the wrong count/max — the fix is preventative. `XexGet*` were both safe stubs; the proper plumbing is now in place if any title (Sylpheed or future) calls them.

43
migration/claude-memory/project_xenia_rs_io_002_volallocunit_2026_05_04.md Normal file
View File

@@ -0,0 +1,43 @@
---
name: KRNBUG-IO-002 vol-info alloc-unit fix landed; cascade FALSIFIED
description: 2026-05-04. nt_query_volume_information_file class-3 returned 2048 bytes/cluster; corrected to canary NullDevice (sectors=0x80, bps=0x200 → 0x10000). Lockstep deterministic, but the audit-006 predicted 7→0 cascade did NOT fire (7→7 unchanged). Volume-info is NOT the priv-11 gate. Next session must probe sub_824A9710 entry to find the real upstream gate.
type: project
originSessionId: cc00c351-3064-4841-a0f7-3ce94e28895e
---
🎯 **KRNBUG-IO-002 (2026-05-04, LANDED branch `xboxkrnl-vol-allocunit/p0-65536-cluster`)** — `nt_query_volume_information_file` class-3 (`FileFsSizeInformation`) at `crates/xenia-kernel/src/exports.rs:1241-1269` corrected from `(total=0x100000, free=0, sectors_per_unit=1, bytes_per_sector=2048)` to canary-NullDevice byte-identical `(total=0x10, free=0x10, sectors_per_unit=0x80, bytes_per_sector=0x200)` (product = 65536). Reference: `xenia-canary/src/xenia/vfs/devices/null_device.h:38-46`. Tests 591 → 592 (added `nt_query_volume_information_file_class3_returns_64k_alloc_unit`). Lockstep `instructions=100000010, swaps=2, draws=0` deterministic across two reruns. sylpheed_n50m oracle still matches its existing golden — **the change is observably a no-op at -n 50M, and remains a no-op at -n 500M**.
**Why:** AUDIT-006 predicted 7→0 collapse of canary-only exports (priv-11 query → XamTaskSchedule → Cache0 callback thread → 0x100c worker spawn → display-init pump). The block-size mismatch was named the SOLE upstream gate per `project_xenia_rs_io_nullfile_2026_05_04.md` and the audit-006 queue file's Tier-0 entry. The fix sketch was prescribed: 4-LOC change, ≤4 lines diff.
**How to apply:** the value change is *correct* (canary-byte-identical), so the branch lands. But it is **not load-bearing for the priv-11 gate**. The audit-006 cascade prediction was **falsified** — the same seven canary-only exports remain `(ExTerminateThread, KeReleaseSemaphore, KeResetEvent, ObCreateSymbolicLink, XamTaskCloseHandle, XamTaskSchedule, XamUserReadProfileSettings)`, identical to the audit-006 set, with `XexCheckExecutablePrivilege=1, XamTaskSchedule=0` unchanged.
**Diagnostic — why the prediction failed.** All 16 `NtQueryVolumeInformationFile` calls in our 500 M trace originate from a single LR `0x82611f38`. Both pre- and post-fix runs show the calls completing with `STATUS_SUCCESS` and never causing a downstream branch. The audit-006/audit-005 premise that `sub_824ABA98` (`VerifyDirBlockSize`) consumes the volume-info reply at the priv-11 gate is therefore likely incorrect, *or* the gate consumes a different information class via a different export entirely (`nt_query_information_file`, `nt_query_full_attributes_file`, an FsCtl `NtDeviceIoControlFile` response, etc.).
**Pre/post snapshot** (audit-006 → post-IO-002):
- canary-only kernel exports: **7 → 7** (identical set)
- `XexCheckExecutablePrivilege`: 1 → 1 (priv=0xA only — priv=0xB never fires)
- `XamTaskSchedule`: 0 → 0
- `swaps`: 2 → 2; `draws`: 0 → 0
- worker spawns: 19 → 18 (within noise; LRs `0x824ac5f0×15 + 0x824cd984×1 + 0x824d2e68×2`)
- `imports@-n 100M` (stable digest): 987686 → **987630** (-56) — slight trajectory shift, but not gate-opening
- `NtQueryVolumeInformationFile` calls: 16 → 16 (no new sites reached)
- parked-handle `signal_attempts`: 0 → 0 (handles 0x1004 / 0x100c / 0x15e0 still parked)
**Stop condition.** Per the IO-002 task brief: *"If audit-006's prediction collapses (7 → 6 instead of 7 → 0), the alloc-unit fix wasn't the SOLE gate after all. Document which of the 7 still classify as REAL_BUT_UNREACHED, capture the new upstream gate from the canary diff, hand back. Do NOT pivot to a second fix this session."* Prediction collapsed cleanly to **zero movement** (7 → 7); branch landed, no second fix attempted, hand-back triggered.
**Trace artifacts** (re-runnable):
- `audit-runs/post-IO-002/ours.log` (692 MB, 5.6 M lines, `RUST_LOG=probe_calls=trace --trace-handles-focus=0x1004,0x100c,0x15e0 -n 500M`)
- `audit-runs/post-IO-002/canary.log` (audit-006 oracle copy; canary build `9467c77f0`)
- `audit-runs/post-IO-002/diff.py`
- `audit-runs/post-IO-002/lock_n100m_run{1,2}.json` (bit-identical)
- `audit-runs/post-IO-002/canary_exports.txt`, `ours_exports.txt`, `canary_only.txt`
**Next-session next-gate hypothesis (untested, ranked by likelihood):**
1. **`sub_824A9710` entry-side probe.** AUDIT-005's instrumentation has never seen the priv-11 site fire in any session. Use `--pc-probe` on the entry of `sub_824A9710` and on every conditional branch inside it; whichever branch exits the function before the priv-11 `XexCheckExecutablePrivilege` call site is the actual gate. Disassemble with `xenia-rs dis --json --at 0x824a9710` and walk top-to-bottom.
2. **Different info-class.** `nt_query_information_file` (class 5 `FileStandardInformation`, class 22 etc.) or `nt_query_full_attributes_file` may be the actual consumer. Our 16 volume-info calls at LR `0x82611f38` complete successfully → **not the gate** even though they were the audit-006 suspect.
3. **Mis-attributed disasm.** AUDIT-005's identification of `sub_824ABA98 = VerifyDirBlockSize(path, expected_alloc_unit_bytes)` came from disasm reading; IO-001's runtime trace already invalidated parts of that attribution. The "verifier rejects 2048" hypothesis is no longer supported by evidence.
4. **A different IOCTL.** `NtDeviceIoControlFile` is now reachable (KRNBUG-IO-001 unblocked it); some FsCtl response we return may be the new gate. The IOCTL code we observed was `0x70000+0x4004` per the IO-001 memory.
**What this session validates about the audit framework:** AUDIT-006's `REAL_BUT_UNREACHED` classification of all 7 entries was correct (they remain unreached). The framework's *triage discipline* held — we did not pull a Tier-1 entry. But its *gate identification* was wrong (Tier-0 hypothesis), which is exactly the failure mode the stop condition was designed to catch. Future audits that hinge on a single causal hypothesis should explicitly enumerate alternative gates and demand probe-evidence rather than disasm-only attribution.
**Headline.** Block-size mismatch closed (fix is correct), but the renderer plateau persists — `swaps=2 draws=0`, parked handles `signal_attempts=0`. The 6-session producer hunt for handles 0x1004/0x100c/0x15e0 remains open. Real gate is upstream of `nt_query_volume_information_file`.

48
migration/claude-memory/project_xenia_rs_io_003_ioctl_2026_05_04.md Normal file
View File

@@ -0,0 +1,48 @@
---
name: KRNBUG-IO-003 NtDeviceIoControlFile cascade landed
description: Real NtDeviceIoControlFile mirroring NullDevice::IoControl for FsCtlCodes 0x70000+0x74004; priv-11 query and XamTaskSchedule fire. 7→3 canary-only exports. Worker count and 0x100c handle unchanged.
type: project
originSessionId: 6fd4fb3a-7b89-4b04-9055-8e6321310ad2
---
# KRNBUG-IO-003 — NtDeviceIoControlFile real impl (2026-05-04, LANDED)
**Branch:** `xboxkrnl-ioctl/p0-fsctl-mountinfo` (no-ff merge to master).
## What changed
- `crates/xenia-kernel/src/exports.rs:90` — `stub_success` → `nt_device_io_control_file`.
- New function body in same file (post `nt_write_file`). Mirrors canary `xboxkrnl_io.cc:645-678` + `null_device.cc`. For FsCtlCode `0x70000`: writes `cache_size/512 (=0x7F8)` at OUT+0 and `512` at OUT+4 (u32 BE). For `0x74004`: writes `0` at OUT+0 and `cache_size = 0xFF000` at OUT+8 (u64 BE). Other codes return `STATUS_INVALID_PARAMETER` with a `tracing::warn!`. Fills `IoStatusBlock` (canary's TODO) with status + bytes-written.
- Stack args 9-10 (OutputBuffer, OutputBufferLength) read from `[sp+0x54]` / `[sp+0x5C]`. **Xbox 360 PowerPC 32-bit ABI**: linkage area sp+0..sp+8, then sp+0x14 starts the parameter save area (8 quadword spill slots × 8 bytes = 64 bytes), so 9th arg lands at sp+0x14+0x40 = sp+0x54. Each slot is 8 bytes wide but holds 4-byte values via `stw` (caller does `stw r5, 84(r1)` and `stw r11, 92(r1)` for the two stack args). Confirmed by disasm of caller `sub_824ABD88:0x824abe04-0x824abe10` and `0x824abe70-0x824abe78`. **No code in xenia-rs ever needed this offset before — first 9+-arg HLE export.**
- 2 unit tests added (one per FsCtlCode); test count 592→594.
- `crates/xenia-app/tests/golden/sylpheed_n50m.json` re-baselined: `instructions=50000004→50000003`, `imports=407362→407255`. `sylpheed_n2m` unchanged.
## Audit-007 prediction scorecard
5/8 sharp predictions held. Recorded for meta-validation:
| # | Prediction | Held? |
|---|---|---|
| (a) cargo test green | 592→594 | ✓ |
| (b) Lockstep determinism | run1≡run2≡run3 (`audit-runs/post-IO-003/lock_n100m_run{1,2,3}.json`) | ✓ |
| (c) `XexCheckExecutablePrivilege` 1→≥2 | 1→2 (priv=0xA + priv=0xB both query) | ✓ |
| (c) `XamTaskSchedule` 0→≥1 | 0→1 | ✓ |
| (e) canary-only exports 7→≤3 | 7→3 (exact lower bound) | ✓ |
| (d) 0x100c worker spawn | still UNCREATED, signal_attempts=0 | ✗ |
| (d) 0x1004 signal_attempts >0 | still 0 | ✗ |
| (f) Worker thread spawn count >19 | unchanged at 19 | ✗ |
**Bonus signal not predicted:** 0x15e0 semaphore: `signal_attempts=0→1` (primary=1, "not stuck — signals consumed correctly") — XamTaskSchedule's downstream pump now runs.
## Why: lockstep digest deltas at -n 100M
`instructions=100000010→100000019` (only +9), `imports=407417→987524` (+2.4×, similar pattern to KRNBUG-XAM-001's HDMI fix). Small instruction delta + huge imports delta = the gate unblocks fast and a tight import-heavy loop runs. `swaps=2 draws=0` plateau persists.
## How to apply
Three exports remain canary-only: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`. The next gate is downstream of XamTaskSchedule — likely the post-task-schedule completion path that should spawn the 0x100c worker. Re-running `--branch-probe` against `sub_824A9710` would now show a NEW exit branch (one of `0x824a996c`, `0x824a9998`, `0x824a9a18`) since the priv-11 site now succeeds. That trace would name the next caller in the chain.
## Trace artifacts
- `audit-runs/post-IO-003/lock_n100m_run{1,2,3}.json` (byte-identical)
- `audit-runs/post-IO-003/lock_n500m.json` (`instructions=500000010 imports=5629676`)
- `audit-runs/post-IO-003/exec_trace_focus_500m.log` (handle focus 0x1004, 0x100c, 0x15e0)

68
migration/claude-memory/project_xenia_rs_io_004_xnotify_listener_2026_05_06.md Normal file
View File

@@ -0,0 +1,68 @@
# KRNBUG-IO-004 — Real XNotify listener (2026-05-06)
## Status
LANDED. Branch `xnotify-listener/p0-startup-enqueue` merged no-ff into master.
## Background
Audit-012 confirmed dispatcher@0x40111890 + vtable@0x820A183C are correctly
populated. The gate was `xnotify_get_next` (xam.rs:363) returning 0 forever,
causing `bc 12, 4*cr6+eq, 0x822F1C20` at 0x822f1be4 to bypass the dispatch arm
at 0x822F1BE8 indefinitely.
## Phase 1.5 result (NOT committed)
Synth-stub auto-enqueued `(0x0A, 1)` on the first `XNotifyGetNext` after listener
registration. Branch-probe (temporarily augmented to print CTR) at PCs
{0x822f1be8, 0x82175338, 0x82173dc8, 0x822f1c04} confirmed:
- Dispatch arm reached: r3=0x40111890 (= mem[0x40111890]) at thunk 0x82175338
- bcctrl target = thunk 0x82175338 → sub_82173DC8 (matches audit-012)
- Returned cleanly to 0x822f1c04 (no abort)
Stub + branch-probe CTR addition reverted. `cargo test --workspace --release`
green at 594.
## Phase 2 implementation (committed)
- `KernelObject::NotifyListener { mask, max_version, queue: VecDeque, waiters }` in `objects.rs`.
- `KernelState::has_notified_startup` + `has_notified_live_startup` in `state.rs`.
- `xam_notify_create_listener` in `xam.rs`: read mask=r3 (qword), max_version=r4 (clamped to 10),
alloc handle, on first listener with `mask & kXNotifySystem` enqueue
`(0x09, 0)` + `(0x0A, 1)`; with `mask & kXNotifyLive` enqueue `(0x02000001, 0x001510F1)` + `(0x02000003, 0)`.
Mirrors `kernel_state.cc:1013-1033` byte-for-byte.
- `xnotify_get_next` in `xam.rs`: handle=r3, match_id=r4, id_ptr=r5, param_ptr=r6.
Pop front (or scan-by-id if match_id != 0). Mask + version filter on enqueue
per `xnotifylistener.cc:38-51`. XNotificationKey: mask_index=bits 25..30,
version=bits 16..24.
- 5 unit tests added: full-mask drains 4 startup notifications in order;
second listener does not re-fire; system-only mask filters live;
version-0 filter drops too-new; unknown-handle returns 0.
- LOC: 119 total (97 impl + 22 scaffolding pattern matches in main.rs/objects.rs/state.rs).
## Cascade-prediction scorecard
- (a) `cargo test --workspace --release`: 594 → 599 PASS
- (b) Lockstep determinism `-n 100M`: instructions=100000012 stable across two reruns; bit-identical diff PASS
- (c) AUDIT-009 21-PC + AUDIT-005 9-PC probe set: 3 newly reachable in `sub_82173DC8` ancestry: `0x822c6870` (fired from 2 worker threads tid=14,15), `0x824563e0` (tid=16), `0x823ddb50` (tid=19). PASS (predicted 1-3)
- (d) Canary-only export delta 7 → 3: `KeResetEvent`, `ObCreateSymbolicLink`, `XamTaskCloseHandle`, `XamTaskSchedule` newly reached. Still canary-only: `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`. PASS (set shrank; specific predictions partial — XamUserReadProfileSettings remained but TaskSchedule fell off, which is reasonable as the post-fix execution path branched differently)
- (e) signal_attempts on parked handles: 0x15e0 = 1 (primary=1, ghost=0) was 0; 0x1004 still 0; 0x100c <UNCREATED> in this -n 500M trace. PASS (predicted >0 on at least one)
- (f) Worker thread count 18 → 20. PASS (delta confirmed)
- (g) draws=0 still expected, VdSwap=2 unchanged. PASS (acknowledged plateau)
## Key runtime values (audit-012-confirmed, re-verified)
- Dispatcher: `0x40111890`
- Dispatcher field at +0: vtable pointer 0x820A183C
- vtable[1] (offset +4): 0x82175338 (XAM thunk → sub_82173DC8)
- Dispatch sequence at 0x822f1be8: `lwz r3, 7944(r25); lwz r5, 84(r31); lwz r4, 88(r31); lwz r11, 0(r3); lwz r11, 4(r11); mtspr CTR,r11; bcctrl`
- Sylpheed listener mask = 0x2F (covers both kXNotifySystem and kXNotifyLive)
- XNotifyGetNext call rate post-fix: 1.49M / -n 500M (was 1.49M pre-fix as well — main.tid=1 is in a frame-poll loop wrapping this call)
## Still-canary-only (post-fix)
1. `ExTerminateThread` — likely fires on worker shutdown which doesn't happen in our trace
2. `KeReleaseSemaphore` — referenced by 0x15e0's producer chain (signal_attempts=1 primary direct on the kernel handle, no Ke shadow)
3. `XamUserReadProfileSettings` — gated on a path past the renderer plateau; provisional next blocker
## Master HEAD
Pre-fix: `50a4887`. Post-fix branch merged no-ff with KRNBUG-IO-004 commit + merge commit.
## Stop-condition adherence
- One step per session: stopped after landing, did not chase ExTerminateThread/KeReleaseSemaphore/XamUserReadProfileSettings.
- LOC budget 120: 119 ≤ 120 PASS.
- C++ runtime audit backlog (CPPBUG-AUDIT-001) untouched.
- No git push.

116
migration/claude-memory/project_xenia_rs_io_nullfile_2026_05_04.md Normal file
View File

@@ -0,0 +1,116 @@
---
name: KRNBUG-IO-001 NullFile-style synth-empty read (2026-05-04, LANDED)
description: One-line fix at exports.rs nt_read_file. Synth empty files return SUCCESS+0 instead of EOF, mirroring canary NullFile::ReadSync. Cascade walked massively (10→7 canary-only exports; 6→19 worker threads).
type: project
originSessionId: 4fddefca-e32e-4f61-b2b2-fb42c949822b
---
**🎯 KRNBUG-IO-001 (2026-05-04, LANDED master `556a8c3`)**
## What sub_824ABA98 actually is
`VerifyDirBlockSize(ANSI_STRING* path, u32 expected_alloc_unit_bytes)`:
NtOpenFile(dir, FILE_OPEN_FOR_FREE_SPACE_QUERY|FILE_DIRECTORY_FILE,
OBJ_CASE_INSENSITIVE) → NtQueryVolumeInformationFile(class=3
FileFsSizeInformation, len=24) → NtClose. Returns the query status if
<0; else 0 if `SectorsPerAllocationUnit * BytesPerSector == r4`,
else `0xC000014F`. Three import thunks: 0x8284DD7C=NtOpenFile,
0x8284DD5C=NtQueryVolumeInformationFile, 0x8284DD6C=NtClose.
## What sub_824ABD88 actually is
`MaybeMountAndIoctl(ANSI_STRING* path, u32 expected)`: calls
sub_824ABC88(path, sp+128) — which compares path against
`\Device\Harddisk0\Partition1` (string at 0x820015A4) and short-circuits
if they match; otherwise opens `\Device\Harddisk0\WindowsPartition`
(0x82001580) and runs NtDeviceIoControlFile(IoCode=0x70000+0x4004=0x74004,
out=16) to read 8 bytes of disk metadata into *out. Then opens `path`
RW (DesiredAccess=0x100003, FILE_NO_INTERMEDIATE_BUFFERING|
FILE_SYNCHRONOUS_IO_ALERT) and runs NtDeviceIoControlFile(IoCode=0x70000,
out=8). Note: leaks the handle on success (no NtClose on the success
path).
## AUDIT-005's attribution was wrong
Static analysis pointed to sub_824ABA98, but the runtime trace
(`probe_calls hw=0 call=NtReadFile r3=0x1008 ... lr=0x824a9814`
followed immediately by `RtlNtStatusToDosError r3=0xc0000011 ...
lr=0x824a97e4`) decisively located the failure at the **`NtReadFile`
call inside sub_824A9710 at 0x824a9810** — well before sub_824ABA98 is
reached. The sub_824ABA98 caller chain runs only after the cache magic
check or recreate path; the chain was unreachable because the function
bailed at the partition0 read.
## sub_824A9710 = LoadOrCreateCacheCatalog
Opens `\Device\Harddisk0\partition0` (NtCreateFile with
FILE_ATTRIBUTE_SYSTEM, ShareAccess=FILE_SHARE_READ, CreateDisposition=
FILE_OPEN, OpenOptions=0x22), reads 1024 bytes from offset 2048,
validates "Josh" magic at byte 0, walks a 2-element slot table for
input r26 (caller's device-id from sub_824A9128), formats
`\Device\Harddisk0\Cache%u` and `\Device\Harddisk0\Cache%u\` paths
into ANSI_STRINGs at sp+112 and sp+120, then calls
`sub_824ABD88(sp+112, r27=0x10000)` and `sub_824ABA98(sp+120, r27=
0x10000)` to verify the cache subdirectory. Caller is sub_824A9AA0,
caller of caller is `main()` at 0x8216EA68 with args (1, 0x10000,
0xFF000) → expected alloc-unit-bytes is **0x10000 = 65536** (NOT
0xFF000, which is r25 used elsewhere as a quota).
## Bug class (β: bit-level / stub gap)
Our synth-empty-file fallback (open_vfs_file when VFS lookup fails)
returns SUCCESS for the open + size=0 file. NtReadFile then returned
STATUS_END_OF_FILE because start_pos=2048 > size=0. Canary mounts
partition0 to a `NullDevice`; `NullFile::ReadSync`
([null_file.cc:24-31](xenia-canary/src/xenia/vfs/devices/null_file.cc))
returns X_STATUS_SUCCESS with bytes_read=0 and never touches the
buffer. Sylpheed's caller pre-zeroes the 1024-byte stack target via
`memset(sp+208, 0, 1024)` (sub_824A9710 prologue), so on return the
buffer is all zeros, the "Josh" magic check fails, and the recreate
path runs.
**Fix (one-line behavioral change):** in `nt_read_file` at
[exports.rs:947](crates/xenia-kernel/src/exports.rs#L947), when
`data.is_empty() && total == 0`, return STATUS_SUCCESS with
information=0 instead of falling into the EOF check. This treats the
synth-empty handle as a NullFile.
## Chain-of-effects (post-fix, master `556a8c3`)
- tests: 590 → 591 (new regression covering NullDevice semantics)
- lockstep: BIT-IDENTICAL across 3 reruns at -n 100M
(`instructions=100000010, imports=987630, swaps=2`)
- sylpheed_n50m golden re-baselined `50000004→50000000`,
`imports 407416→407362`
- canary kernel-call diff: **10 → 7 missing exports**.
Newly matched at -n 500M: XeCryptSha, XeKeysConsolePrivateKeySign,
NtDeviceIoControlFile (the cache-recreate path runs through to
NtWriteFile). Still canary-only: ExTerminateThread, KeReleaseSemaphore,
KeResetEvent, ObCreateSymbolicLink, XamTaskCloseHandle, XamTaskSchedule,
XamUserReadProfileSettings.
- boot trajectory: at -n 500M now spawns **19 worker threads** (was
~6 pre-fix). Notably tid=10 entry=0x82178950 (the parked-handle 0x1004
worker) and tid=16 entry=0x82170430 (the 0x15e0 worker) NOW spawn.
- parked-handle 0x1004 still `signal_attempts=0` (singleton ctor at
lr=0x824a9f6c). Handles 0x100c and 0x15e0 are now `<UNCREATED>` because
cascade walked past them and handle assignments shifted forward;
**new parked sites**: 0x12fc, 0x1600, 0x1040, 0x10b8, 0x15e8, 0x1014,
0x101c, 0x10bc, 0x1044, plus 0x42450b5c (still parked, tid=6).
## Next-frontier blockers
1. **XamTaskSchedule cluster** (priv-11 path) — the next-up canary
cascade step.
2. **Block-size mismatch in nt_query_volume_information_file**:
currently returns SectorsPerAllocUnit=1, BytesPerSector=2048 →
product=2048. Sylpheed expects 0x10000=65536. When sub_824ABA98 is
eventually reached, it will return 0xC000014F. This is an obvious
downstream gap if the recreate path's sub_824ABD88 call chain ends
up triggering a verify path that returns to sub_824ABA98 with a
tighter expected size.
3. **Many new parked handles** — 9 unique sites; the cascade is
producing more events than we have producers for. Need a fresh
--trace-handles-focus run on the new handles to characterize.
## Files touched
- [exports.rs:947](crates/xenia-kernel/src/exports.rs#L947): inserted
9-line synth-empty bypass before the EOF check.
- [exports.rs:4001](crates/xenia-kernel/src/exports.rs#L4001):
`nt_read_file_synth_empty_file_returns_success_with_zero_bytes`
regression covering buffer-untouched + IOSB.information=0 +
STATUS_SUCCESS + completion-event signal.
- [tests/golden/sylpheed_n50m.json](crates/xenia-app/tests/golden/sylpheed_n50m.json):
re-baselined (`instructions 50000004→50000000`, `imports
407416→407362`).

44
migration/claude-memory/project_xenia_rs_kernel_ke_resume_thread_2026_05_06.md Normal file
View File

@@ -0,0 +1,44 @@
# KRNBUG-KE-001 — real `KeResumeThread` (LANDED 2026-05-06)
## Summary
Replaced no-op `ke_resume_thread` (exports.rs:3658-3664 — set r3=0, ignored r3) with a real impl per canary `xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_threading.cc:216-227`. Mirrors `nt_resume_thread`'s plumbing (resolve_pseudo_handle → scheduler.find_by_handle → resume_ref). Returns `STATUS_SUCCESS` if the KTHREAD-pointer-as-handle resolves, `STATUS_INVALID_HANDLE` otherwise.
Branch: `ke-resume-thread/p0-canary-mirror` — local commit + no-ff merge. Tests 600 → 601. Lockstep `instructions=100000003 imports=987516` deterministic ×2.
## Cascade-prediction scorecard (audit-018 → post-fix)
- **A — thread liveness PASS**: tids 9 (entry=0x824D2878) and 10 (entry=0x824D2940) transition `Blocked(Suspended)` → ran prologue → now `Blocked(WaitAny)` on audio buffer-completion semaphores 0x828A3254 / 0x828A3230 (handle decimal 2190094932 / 2190094896).
- **B — counters PARTIAL FAIL**: `NtSetEvent 667→3334` (~5× rise). `KeResumeThread=2` real for first time. `KeReleaseSemaphore=0` (still). `XAudioSubmitRenderDriverFrame=0` (still). Workers reached prologue but parked on a downstream consumer wait before the audio render-tick semaphore-release loop.
- **C — canary-only delta FAIL (predicted 2→1, actual 2→2)**: `ExTerminateThread`, `KeReleaseSemaphore` both still canary-only.
- **D — γ-cluster blocker FAIL**: `--pc-probe=0x82184318,0x82184374` armed, neither fires. `--dump-addr=0x828F4070` armed, no DUMP. Listener struct `[+64]` unchanged. `--trace-handles-focus=0x1004,0x100c,0x1020,0x15e4` shows all 4 still `signal_attempts=0`.
## Milestone status
- Renderer cluster cascade collapsed? **NO**.
- signal_attempts > 0 on parked handles? **NO**.
- draws > 0? **NO** (swaps=2 draws=0 plateau intact).
## Why C and D didn't fire
The audio render-frame ticker thread (entry=0x824D2878) is per-canary unblocked by `KeResumeThread` and immediately enters its body. In our run the body advances past prologue (PC 0x824D2878 → currently parked at 0x824D2990 / 0x824D28D0) but the gate is a **downstream** semaphore the audio infrastructure hasn't populated. That gate is itself part of a separate bug class — the consumer-side semaphore producer at 0x828A3230 / 0x828A3254 is gated by something else (likely the audit-009/-016/-017 γ-cluster `[0x828F4070+64]==-1`).
The fix is **necessary but not sufficient**: it cleanly attributes the renderer plateau to a downstream blocker, narrowing the search.
## Verification
- `cargo test --workspace --release` clean. New test `ke_resume_thread_unblocks_suspended_worker` covers Suspended→Ready transition + INVALID_HANDLE branch.
- `cargo test -p xenia-app --test sylpheed_oracles --ignored` green after re-baselining `sylpheed_n50m.json` (instructions 50000003→50000011, imports 407255→407247; draws/swaps unchanged at 0/2).
## Files touched
- `crates/xenia-kernel/src/exports.rs` (12 LOC — fix + 41 LOC test)
- `crates/xenia-app/tests/golden/sylpheed_n50m.json` (re-baseline)
- `audit-findings.md` (new KRNBUG-KE-001 section)
- `audit-runs/audit-006/canary_export_queue.md` (status update)
## Trace artifacts
- `audit-runs/post-ke-resume/lockstep_run{1,2}.json` — lockstep determinism
- `audit-runs/post-ke-resume/run.{log,err}` — 500M cascade verification
- `audit-runs/post-ke-resume/probe.{log,err}` — γ-cluster pc-probe + dump-addr
- `audit-runs/post-ke-resume/handles.{log,err}` — `--trace-handles-focus`
## Recommended next session — AUDIT-019 (memory-watch on `[0x828F4070+64]`)
Audit-017 Option B. With KE-001 landed, the discipline gate cleanly attributes the renderer plateau to the listener-struct field rather than to a stub upstream. Memory-watch instrumentation should identify the writer that canary calls but we don't.
## Master HEAD
Pre-session: `7ed6192`. Post-merge HEAD: see `git log master --oneline | head -3` after merge.

123
migration/claude-memory/project_xenia_rs_kernel_stashhandle_2026_05_06.md Normal file
View File

@@ -0,0 +1,123 @@
# KRNBUG-α-006 — `ensure_dispatcher_object` writes XObj signature + handle
Date: 2026-05-07 (calendar carries the same date the audit-024A canary diff documented this divergence)
Branch: `xobj-stashhandle/p0-canary-mirror` (merged --no-ff into master `de5a15e`)
Status: LANDED. Tests 604 → 605. Lockstep deterministic.
## Background
Audit-023 + audit-024A documented byte-level divergence at `0x828F4838+0x08`:
canary stores `"XEN\0"` (kXObjSignature fourcc) at +0x08 and a kernel handle
(`0xF8000034` in the captured dump) at +0x0C. Ours had zeros.
Canary's writer is `XObject::StashHandle(X_DISPATCH_HEADER*, uint32_t handle)`
at `xenia-canary/src/xenia/kernel/xobject.h:253-256`:
```c++
header->wait_list.flink_ptr = kXObjSignature; // +0x08
header->wait_list.blink_ptr = handle; // +0x0C
```
Two callers in canary:
- `XObject::SetNativePointer` (xobject.cc:392) when kernel allocates a native
object and binds an existing dispatcher pointer to it.
- `XObject::GetNativeObject` (xobject.cc:474) on first guest-allocated KEVENT/
KSEMAPHORE adoption — exactly the scenario our `ensure_dispatcher_object`
models.
## Fix
`crates/xenia-kernel/src/exports.rs:~3097`, after the host-shadow insert, write:
```rust
mem.write_u32(ptr + 0x08, 0x58454E00);
mem.write_u32(ptr + 0x0C, ptr);
```
Stash handle is `ptr` itself because our `state.objects` is keyed by guest
pointer. Game reads the magic at +0x08 to recognize an already-adopted
dispatcher; the handle at +0x0C is opaque to the game (canary uses it as a
host-side handle map key — same role our pointer-key plays).
7 LOC in impl (3 lines incl. 1 comment). 27 LOC in tests. 0 deletions. Hard
cap of 30 LOC on impl met.
## Tests
New unit test `ensure_dispatcher_object_stamps_xen_signature_and_handle`
asserts both writes against `ke_set_event` driven adoption. Updated
`ensure_dispatcher_object_ignores_unknown_type` to additionally assert
+0x08 / +0x0C remain zero on an unsupported type byte. Workspace tests
604 → 605 pass.
## Lockstep determinism
`cargo run --release -p xenia-app -- check sylpheed.iso --stable-digest -n 100_000_000`
produced identical output across 2 reruns:
```
instructions=100000003 import_calls=987516 unimplemented=0
```
Identical to pre-fix master HEAD `d9e40d3` lockstep — writeback is host-side,
adds zero guest instructions. `sylpheed_n50m` golden passes unchanged.
## Cascade observation (-n 500M, --halt-on-deadlock)
| Metric | Pre-fix | Post-fix | Notes |
|---|---|---|---|
| `0x828F4838+0x08` | zeros | zeros | Guest never calls Ke* on this dispatcher (uses other adoption path) |
| `0x828F4838+0x00` (type) | 0x01 | 0x01 | Sync event header, populated by guest, not us |
| Worker count | 20 | 20 | unchanged |
| `KeReleaseSemaphore` | 0 | 0 | canary-only |
| `XAudioSubmitRenderDriverFrame` | 0 | 0 | canary-only |
| `ExTerminateThread` | 0 | 0 | canary-only |
| `NtSetEvent` | 3334 | 3334 | unchanged |
| `XamUserReadProfileSettings` | 2 | 2 | unchanged |
| `VdSwap` | 2 | 2 | unchanged |
| `KeSetEvent` / `KeResetEvent` / `KeWaitForSingleObject` | 1 / 1 / 5 | 1 / 1 / 5 | unchanged |
`ensure_dispatcher_object` is hit only on direct PKEVENT / PKSEMAPHORE-pointer
paths (KeSetEvent=1 / KeResetEvent=1 — only ~1-5 invocations per run); most
guest kernel-object touches are handle-based and never traverse this code.
At 0x828F4838 in particular, the guest never invokes a Ke API with a pointer
to it — adoption in canary likely happens via a different export path
(possibly the kernel-allocated `SetNativePointer` lifecycle, which we don't
model in the same way).
Per the task brief: "may move cascade or may not; lands regardless because
canary-divergent." No cascade ripple observed; expected.
## Bug-class
α (load-bearing-stub-omission). Mirror landed; the side-effect-on-guest-
memory was missing from our impl. Symmetric to the XamUserGetSigninState
fix landed pre-this-session — both are canary-correctness restorations
without sharp cascade hypothesis.
## Discipline gate
Boxes 2/4/5 pass. Box 1 ("sharp cascade prediction") explicitly waived per
task brief. Box 3 ("doesn't break lockstep") passes (digest unchanged).
## Trace artifacts
- `audit-runs/post-stashhandle/dump-500m.log` (-n 500M dump-addr=0x828F4838 + counters)
- `audit-runs/post-stashhandle/dump-50m.log` (-n 50M short run, no halt)
## Master HEAD
`de5a15e` (merge of `xobj-stashhandle/p0-canary-mirror` c03f2bc into master).
Not pushed.
## Next
The β/γ-cluster blocker remains unresolved. Audit-024A's `XAudioSubmitRender
DriverFrame=0` lead is independent of StashHandle; the audio-thread-start
gate is the natural next target. Sister session 025 was running an audio-
thread-start diagnostic in parallel — coordinate with its findings.
Audit-024A's hypothesis that the StashHandle write at 0x828F4838 might
unblock something is **observationally falsified** at -n 500M post-fix.
The canary's "XEN\0+handle" stamp at that address is necessary for canary
correctness, not a load-bearing trigger for our cascade.

176
migration/claude-memory/project_xenia_rs_m3_followup_real_parallelism_plan.md Normal file
View File

@@ -0,0 +1,176 @@
---
name: M3 follow-up — design for actual N=6 per-HW-thread parallelism (2026-04-26)
description: Hand-off memory for the next session. Current M3 substrate (Arc<Mutex<KernelState>>, phaser, per-thread block caches, ctx.hw_id, reservation activation) is in place and golden-stable across 6 flag combos. Real N=6 parallelism deferred to a focused follow-up session because it requires recreating ~300 lines of run_execution in a worker-decomposed form. This memo specifies exactly what that session needs to do.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## Current state (verified clean)
411 tests pass. All 6 flag combinations (default, `--parallel`, `--reservations-table`, `--gpu-inline`, and combos) match `golden/sylpheed_n2m.json` at -n 2M. Sylpheed -n 30M `--parallel --halt-on-deadlock` boots to VdSwap=2 with halts==0.
Substrate that's already done and the next session can build on:
- `Arc<Mutex<KernelState>>` wrap (M3.3) — `cmd_exec_inner` already supports the wrap; the worker thread variant exists.
- `Phaser` primitive (M3.1) — `arrive_and_wait`/`skip`/`shutdown`/`arrive_and_wait_timeout`, 6 unit tests.
- Per-thread block caches (M3.2a) — `[BlockCache; HW_THREAD_COUNT]` indexed by `hw_id`.
- `PpcContext.hw_id` + `PpcContext.reservation_table` (M3.7) — populated by `Scheduler::spawn` / `install_initial_thread` / migration.
- `ReservationTable` with self-describing `enable()`/`is_enabled()` (M3.7).
- `lwarx`/`stwcx.`/`ldarx`/`stdcx.` route through the table when `ctx.reservation_table.is_enabled()` (M3.7).
- `--parallel` CLI flag wired (currently spawns N=1 worker = same as lockstep).
## What the next session needs to do
Convert the N=1 spawn into N=6 with **real parallelism** via the **mem::replace + per-iteration kernel lock** pattern. Workers parallelize during `step_block` (no lock held); serialize at the kernel mutex for `pick_runnable` / `mem::replace` / `commit` / `call_export`.
### High-level design
```text
N=6 worker threads, each with:
- hw_id: 0..6
- own BlockCache
- clone of Arc<Mutex<KernelState>>
- clone of Arc<GuestMemory>
- clone of Arc<Phaser>
- clone of Arc<AtomicBool> shutdown
Worker loop:
while !shutdown.load(Acquire) {
let stolen = {
let mut k = kernel.lock().unwrap();
// Pick runnable on this slot
k.scheduler.begin_slot_visit(hw_id);
let r = k.scheduler.current?;
let tid = k.scheduler.slots[hw_id].runqueue[r.idx].tid;
let ctx = std::mem::replace(
k.scheduler.ctx_mut_ref(r),
PpcContext::new(), // placeholder
);
Some((r, tid, ctx))
}; // kernel lock released
let Some((r, tid, mut ctx)) = stolen else {
phaser.skip(hw_id);
thread::sleep(Duration::from_micros(100));
continue;
};
// STEP_BLOCK runs WITHOUT kernel lock — true parallelism here
let block = block_cache.lookup_or_build(ctx.pc, &*mem);
let result = step_block(&mut ctx, &*mem, block);
// Reacquire and commit
{
let mut k = kernel.lock().unwrap();
// Find current ThreadRef by tid (handles peer-worker migration)
let target_r = k.scheduler.find_by_tid(tid).unwrap_or(r);
*k.scheduler.ctx_mut_ref(target_r) = ctx;
// Handle StepResult
match result {
StepResult::SystemCall => {
k.scheduler.current = Some(target_r);
// Resolve thunk + dispatch
k.call_export(module, ordinal, &*mem);
k.scheduler.current = None;
}
StepResult::Halt(_) => { /* mark exited */ }
StepResult::Continue => {}
// ... other variants (UnimplOp, Trap, etc.)
}
k.scheduler.end_slot_visit();
}
phaser.arrive_and_wait(hw_id);
}
```
### Cross-cutting work (the coordinator thread)
Between phaser barriers, ONE thread does:
- `kernel.interrupts.tick_vsync(stats.instruction_count)` + setting D1MODE_VBLANK_VLINE_STATUS bit
- `state.fire_due_timers(now)` — wakes timer waiters
- `try_inject_graphics_interrupt` + IRQ delivery
- GPU interrupt drain (`kernel.gpu.take_pending_interrupts()` → `kernel.interrupts.queue_interrupt`)
- Halt-on-deadlock detection
- Instruction-count atomic update (workers each post their per-iter count)
- Stats aggregation
**Implementation choice**: either (a) main thread does it after spawning workers, looping `phaser.coordinator_wait()`-style; or (b) one of the workers (hw_id 0) elects to do it after each phaser barrier. (a) is cleaner.
### Specific non-trivial issues the session must handle
1. **Cross-worker migration via `find_by_tid`.** When Worker A is in `step_block` and Worker B's `KeSetAffinityThread` (inside its own `call_export`) migrates the thread Worker A is executing, A's `r: ThreadRef` becomes stale. Solution: `find_by_tid(tid)` lookup on commit; `tid` is stable across migration. Defaults to `r` if lookup fails (shouldn't happen but defensive).
2. **`scheduler.current` racing.** Workers each set `scheduler.current` at pick time and clear at end. Under the kernel mutex these are serialized — but a worker that releases the lock with `scheduler.current = Some(my_r)` leaves it set when other workers acquire. Solution: clear `scheduler.current = None` BEFORE releasing the lock (after the `mem::replace`). Re-set it ONLY around `call_export`.
3. **Halt sentinel restoration.** `StepResult::Halt(LR_HALT_SENTINEL)` triggers IRQ-callback restore in the existing run_execution. The worker must call `interrupts.saved.take().restore(...)` under the kernel lock if `interrupts.injected_ref == Some(my_r)`. Carved from current `run_execution`'s body.
4. **DB writer thread-safety.** `xenia_analysis::DbWriter` is not Sync. Either gate per-instruction trace recording (which `--parallel` should disable), or wrap in Mutex per-worker. Simplest: assert `db_writer.is_none()` for parallel mode.
5. **Debugger pre-step hooks.** `Debugger::wants_hooks()` + per-instruction observation requires holding kernel lock during step (defeats parallelism). Simplest: assert no debugger hooks in parallel mode.
6. **Block cache lifetime.** Each worker owns its `BlockCache`. The cache references decoded blocks via raw pointer (the `block_ptr` pattern in current run_execution to bridge `lookup_or_build`'s `&dyn MemoryAccess` borrow with `step_block`'s subsequent call). The pattern is sound per-worker because each worker's cache + step_block runs single-threaded on its own thread.
7. **Reservation table activation.** `--parallel` already implies `kernel.reservations.enable()`. Per-ctx fields (`reservation_table`, `hw_id`) are already wired. Workers' `lwarx`/`stwcx.` will automatically route through the table. Verify the M2.2 stress test (`concurrent_lwarx_stwcx_serializes`) still holds under real parallel guest workloads.
8. **Timer wake fairness.** `kernel.fire_due_timers` walks `pending_timer_fires` and signals events. Under parallel workers, the timer-fire might race with a worker's wait acquisition. The existing kernel mutex serializes, so this works — but worth a stress test (timers + parallel mode).
9. **Halt-on-deadlock detection.** Current run_execution checks `kernel.scheduler.has_live_thread()` per round. Coordinator should do the same; on detected deadlock, signal shutdown to workers via `shutdown.store(true, Release)` + `phaser.shutdown()`.
### Rough size estimate
- New `run_execution_parallel` function: ~250-350 lines
- `cmd_exec_inner` integration: ~30 lines (mostly already done; flip --parallel from N=1 to call new function)
- Coordinator helper functions: ~80-100 lines
- Tests: ~50-100 lines (mainly stress tests in xenia-app/tests)
## Verification matrix the next session must pass
| Check | Expected |
|---|---|
| `cargo test --workspace` | ≥ 411 passed, 0 failed |
| Lockstep golden (no flags) | matches |
| `--gpu-inline` golden | matches |
| `--reservations-table` golden | matches |
| `--gpu-inline --reservations-table` golden | matches |
| `--parallel` golden at -n 2M | matches (no swaps yet) |
| `--parallel --reservations-table` golden at -n 2M | matches |
| `--parallel` -n 30M `--halt-on-deadlock` | exit 0, VdSwap=1 + VdSwap=2 |
| 100× `--parallel` -n 50M `--halt-on-deadlock` | all exit 0 |
| `--parallel` perf vs lockstep at -n 30M | ≥ 1.5× wall-time speedup on a ≥6-core host |
The 100× stress test is THE gate that surfaces lost-wakeups, lock-order inversions, and ABA hazards.
## Files the next session will most likely touch
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) — new `run_execution_parallel` function; carve out coordinator helpers (`tick_vsync_and_timers`, `drive_gpu_round`, `drain_interrupts`, `check_halt_on_deadlock`)
- [crates/xenia-cpu/src/scheduler.rs](xenia-rs/crates/xenia-cpu/src/scheduler.rs) — `find_by_tid` already exists at line 487; verify stability under multi-worker calls
- [crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs) — `call_export` may need a `caller_hw_id: u8` param; or workers set `scheduler.current` before calling
## Why this isn't done in this session
The plan said "be pedantic about concurrency correctness". A 300-line carving-out of `run_execution` is too large to verify safely in a single session without a per-substep verification cadence. Each piece (worker loop, cross-worker migration handling, coordinator, etc.) needs golden + stress-test gates. Splitting into dedicated focused work is more responsible than racing.
## Memory files for this session's work (already written)
- [project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md](project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md) — M3.3 + M3.4 (kernel wrap + N=1 spawn)
- [project_xenia_rs_m3_step_07_reservation_activation.md](project_xenia_rs_m3_step_07_reservation_activation.md) — M3.7 (reservations in interpreter)
- [project_xenia_rs_m3_step_08_verification.md](project_xenia_rs_m3_step_08_verification.md) — M3 session verification
- [project_xenia_rs_m3_followup_real_parallelism_plan.md](project_xenia_rs_m3_followup_real_parallelism_plan.md) — this hand-off
## Resume command
To resume in the next session:
```bash
cd "/home/fabi/RE Project Sylpheed/xenia-rs"
cargo test --workspace
./target/release/xenia-rs check sylpheed.iso -n 2_000_000 \
--expect crates/xenia-app/tests/golden/sylpheed_n2m.json --parallel
# Both should pass before starting work.
```
Then write `run_execution_parallel` per the design above. Verify after each substep:
1. Worker loop body (no spawn yet) — call from main thread, verify lockstep golden.
2. Add coordinator helpers — verify lockstep still works.
3. Spawn N=1 — verify lockstep golden under `--parallel`.
4. Scale to N=6 — verify sylpheed boots; check 30M halts==0.
5. Stress 100x.

57
migration/claude-memory/project_xenia_rs_m3_realpar_step_01.md Normal file
View File

@@ -0,0 +1,57 @@
---
name: M3 real-par Step 01 — coordinator helpers carved out (2026-04-26)
description: Three free fns coord_pre_round / coord_idle_advance / coord_post_round + RoundCtl enum carved out of run_execution. Pure motion refactor, lockstep bit-identical. 430 tests pass, all 6 flag combos match golden.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## What landed
`run_execution` in [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) had its outer-loop body shrunk by ~200 lines via three helper functions:
- **`coord_pre_round(kernel, stats, max_instructions, ips_limit, throttle_start, &shutdown) -> RoundCtl`** — per-round prologue. Holds the SHUTDOWN_CHECK_MASK / IPS-throttle / heartbeat block, vsync ticker (with `D1MODE_VBLANK_VLINE_STATUS` bit 0 set when fire), `fire_due_timers`, `try_inject_graphics_interrupt`. Returns `BreakOuter` only when budget reached or UI shutdown.
- **`coord_idle_advance(kernel, halt_on_deadlock, &shutdown, stats) -> RoundCtl`** — invoked when `round_schedule()` is empty. Advances time to earliest pending deadline, fires timers, handles deadline wakes. On hard deadlock either dumps diagnostics + halts or force-wakes via `STATUS_TIMEOUT`.
- **`coord_post_round(kernel, mem, stats, instrs_at_round_start) -> RoundCtl`** — per-round epilogue. Calls `end_slot_visit`, drives the inline GPU proportional to executed instructions, drains GPU-side pending interrupts via `take_pending_interrupts`, and breaks when no live HW threads remain.
`RoundCtl` is a `BreakOuter | Continue` enum. The constants `SHUTDOWN_CHECK_MASK` and `HEARTBEAT_MASK` moved into `coord_pre_round`. `LR_HALT` stays in `run_execution` (consumed by the per-slot body).
## Why
Step 01 of the M3 real-parallelism plan: the per-HW-thread parallel scheduler (Step 04) needs the coordinator to run these phases between phaser barriers. Carving them out so both lockstep and parallel paths can call them keeps a single source of truth for the sync logic and lets every substep land lockstep-bit-identical.
## Files touched
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- +RoundCtl enum
- +coord_pre_round (~70 lines)
- +coord_idle_advance (~80 lines)
- +coord_post_round (~50 lines)
- run_execution body shrunk: prologue / idle / postlogue replaced with `match` calls
- `SHUTDOWN_CHECK_MASK` / `HEARTBEAT_MASK` constants moved into the helper
## Subtle pattern note
The helpers take `shutdown: &Option<Arc<AtomicBool>>` (not the original owned `Option<Arc<AtomicBool>>`). Rust's match-ergonomics implicitly borrow the contents, so the original `if let Some(ref flag) = shutdown` patterns had to drop the `ref` keyword inside the helpers. Took two iterations to compile.
## Verification
- `cargo build --release -p xenia-app`: clean (one warning-free build).
- `cargo test --workspace`: 430 passed, 0 failed (≥411 baseline ✓).
- All 6 golden combos at -n 2M match: `default`, `--parallel`, `--reservations-table`, `--gpu-inline`, `--gpu-inline --reservations-table`, `--parallel --reservations-table`.
## Regression-fix breadcrumbs
If a regression appears after this step:
1. **Golden mismatch in lockstep**: the carve must be observation-equivalent. If the digest drifts, check that the order of operations in `coord_pre_round` matches the original (max-budget → IPS → SHUTDOWN_CHECK → heartbeat → vsync → fire_due_timers → try_inject_graphics_interrupt). Off-by-one ordering with `fire_due_timers` vs `try_inject_graphics_interrupt` changes which interrupts land.
2. **Golden mismatch with `--parallel`**: same root cause as (1); the parallel branch wraps around `run_execution` unchanged in this step.
3. **Compile error about `ref` in shutdown match**: dropped intentionally; match-ergonomics implicit borrow.
4. **`coord_idle_advance` not breaking when expected**: the original code had `info!()` inside the `else` branch then `break` — keep this structure. The helper returns `BreakOuter` after the `info!()`.
## What this does NOT yet do
- No worker-loop split (Step 02).
- No drop-and-reacquire pattern (Step 03).
- No N=6 spawn (Step 04).
- The per-slot body (lines 1551-1959) is untouched.
## Test count: 430 (was 430 pre-step; this is a pure motion refactor).

82
migration/claude-memory/project_xenia_rs_m3_realpar_step_02.md Normal file
View File

@@ -0,0 +1,82 @@
---
name: M3 real-par Step 02 — WorkerCtx + worker_prologue/worker_epilogue (2026-04-26)
description: Per-slot body of run_execution split into worker_prologue (under-lock prologue + per-instr path inline) + worker_epilogue (block-cache StepResult handling). Per-HW-slot WorkerCtx owns its own block cache + decode cache. Lockstep bit-identical; 430 tests pass; all 6 golden combos match.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## What landed
The per-slot body inside `run_execution` (originally lines 1551-1959) split into three reusable pieces:
1. **`struct WorkerCtx`** in [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- `hw_id: u8`
- `block_cache: BlockCache`
- `decode_cache: DecodeCache`
- `force_per_instr: bool`
- `WorkerCtx::new(hw_id, force_per_instr)` constructor.
2. **`PrologueOutcome`** enum: `Continue` (inline-handled), `BreakOuter`, `StepBlock { tid, thread_ref, block_ptr, pc_before }` (block-cache step pending).
3. **`SlotOutcome`** enum: `Continue`, `BreakOuter`.
4. **`worker_prologue`** function:
- Calls `begin_slot_visit`.
- Halt-sentinel detect + restore.
- Import-thunk dispatch (calls `kernel.call_export`).
- Unmapped-PC fault check.
- Decides block-cache fast path vs per-instruction observation.
- For block-cache: looks up via `wc.block_cache.lookup_or_build`, returns `StepBlock`.
- For per-instruction (debugger / DB writer / `XENIA_FORCE_PER_INSTR=1`): runs `step_cached` with `wc.decode_cache`, db logging, post-step hook, decrement_quantum, should_break — entirely inline.
5. **`worker_epilogue`** function:
- Charges `executed` quantum decrements.
- Applies `StepResult` (Continue/SystemCall/Unimplemented/Trap/Halted), with the `Halted` arm returning `BreakOuter` only when the halting thread is `INITIAL_GUEST_TID`.
- Debugger should_break check.
`run_execution`'s outer-loop body now calls `worker_prologue`, dispatches based on the outcome, and on `StepBlock` runs `step_block(ctx, mem, &*block_ptr)` followed by `worker_epilogue`. The lockstep loop holds the kernel state borrowed straight through (no lock-release window — that's Step 03).
## Why
Step 02 of the M3 real-parallelism plan: the parallel scheduler (Step 04) needs the per-slot body decomposed so it can release the kernel mutex around `step_block` (Step 03's drop-and-reacquire pattern). With prologue and epilogue as separate functions, lockstep keeps a tight wrapping but parallel can interleave a `drop(g) ... step_block ... g = lock()` between them.
Per-worker `BlockCache` and `DecodeCache` (instead of one shared `DecodeCache`) is the precondition for parallel mode: each worker owns its caches so peers don't contend on cache mutation.
## Files touched
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- +`WorkerCtx` (struct + constructor)
- +`PrologueOutcome` + `SlotOutcome` enums
- +`worker_prologue` (~200 lines, owns the entire per-slot prologue + per-instruction inline path)
- +`worker_epilogue` (~70 lines, owns the block-cache StepResult handling)
- `run_execution`: replaced `[BlockCache; 6]` + shared `DecodeCache` with `[WorkerCtx; 6]`; replaced ~400-line per-slot body with ~50-line dispatch on `PrologueOutcome`.
- Removed locally-scoped `LR_HALT` constant + `BlockCache`/`DecodeCache`/`step_cached`/`StepResult`/`INITIAL_GUEST_TID`/`PpcOpcode` imports (now scoped inside the helpers).
## Critical correctness invariants preserved
- **Halt-sentinel restore** runs in `worker_prologue` before any step → still under the kernel lock when Step 03 lands.
- **Import-thunk path** stays fully under the kernel lock (call_export reads scheduler.current); never released around it.
- **Block-cache raw-pointer pattern**: prologue produces `*const DecodedBlock` from `wc.block_cache.lookup_or_build(pc, mem)`. The pointer remains valid through the step + epilogue because `wc.block_cache` is owned by the worker and isn't mutated again until the next prologue iteration. Documented in the safety comment on `worker_epilogue`.
- **`scheduler.current`** is set by `begin_slot_visit` inside the prologue; the lockstep path leaves it set through step + epilogue (because `end_slot_visit` is in `coord_post_round` after the slot loop). Step 04 will move `end_slot_visit` to clear `current` before unlock.
## Verification
- `cargo build --release -p xenia-app`: clean.
- `cargo test --workspace`: 430 passed, 0 failed.
- All 6 golden combos at -n 2M match: `default`, `--parallel`, `--reservations-table`, `--gpu-inline`, `--gpu-inline --reservations-table`, `--parallel --reservations-table`.
## Regression-fix breadcrumbs
If a regression appears after this step:
1. **Golden mismatch in lockstep**: most likely a missed instruction-count or quantum-decrement. The block-cache path's stats update (`stats.instruction_count.wrapping_add(executed)`) and N-time `decrement_quantum` calls landed in `worker_epilogue`. The per-instruction path's `stats.instruction_count += 1` and single `decrement_quantum` landed in `worker_prologue`'s per-instr branch.
2. **Golden mismatch with `--parallel`**: same root cause — the parallel branch wraps `run_execution` unchanged in this step. If only `--parallel` mismatches but lockstep matches, suspect `wc.decode_cache` per-worker behavior. (Decode cache results are deterministic given PC + page_version + raw instruction; per-worker should never change behavior.)
3. **`scheduler.current` is None panic**: `worker_prologue` does `kernel.scheduler.current.expect("begin_slot_visit set scheduler.current to Some when slot has runnable thread")`. This panic would fire if `pick_runnable` returned None for a slot that `round_schedule` reported as runnable — a scheduler invariant violation, not a bug introduced by this step.
4. **Borrow checker errors after editing the per-slot loop**: `kernel.scheduler.ctx_mut_ref(thread_ref)` borrows `kernel.scheduler` mutably; the borrow must end before the next `kernel.scheduler.*` call. The current dispatch uses an explicit scope `{ let ctx = ...; step_block(ctx, mem, block) }` to bound the borrow.
## What this does NOT yet do
- No drop-and-reacquire of the kernel lock around `step_block` (Step 03).
- No N=6 worker spawn (Step 04).
- No `find_by_tid` on epilogue commit (Step 04 — needed only when peers can migrate during the unlock window; in lockstep there are no peers).
## Test count: 430 (was 430 pre-step; pure motion refactor).

97
migration/claude-memory/project_xenia_rs_m3_realpar_step_03.md Normal file
View File

@@ -0,0 +1,97 @@
---
name: M3 real-par Step 03 — drop-and-reacquire around step_block (N=1) (2026-04-26)
description: New run_execution_parallel function with per-round mutex acquire/release and a drop-guard window around step_block. --parallel branch now calls it instead of run_execution. Single worker, uncontended unlock window. 430 tests pass; all 6 golden combos match; sylpheed -n 30M --parallel reaches VdSwap=2, halts==0 in 3866ms.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## What landed
A new function `run_execution_parallel(mem, &Arc<Mutex<KernelState>>, ...)` in [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) that does the per-round locking dance internally:
```text
loop {
let mut guard = kernel_arc.lock();
coord_pre_round(&mut *guard, ...); // budget / vsync / timers / IRQ
guard.scheduler.begin_round();
let order = guard.scheduler.round_schedule();
if order.is_empty() {
coord_idle_advance(&mut *guard, ...);
drop(guard); continue;
}
for hw_id in order {
match worker_prologue(...) {
Continue => continue,
BreakOuter => break 'outer,
StepBlock { tid, thread_ref, block_ptr, pc_before } => {
let mut ctx_taken = mem::replace(
guard.scheduler.ctx_mut_ref(thread_ref),
PpcContext::new(),
);
let cycle_before = ctx_taken.cycle_count;
drop(guard); // ← unlock
let result = step_block(&mut ctx_taken, mem, &*block_ptr);
let executed = ctx_taken.cycle_count - cycle_before;
guard = kernel_arc.lock(); // ← relock
let target_ref = tid
.and_then(|t| guard.scheduler.find_by_tid(t))
.unwrap_or(thread_ref);
*guard.scheduler.ctx_mut_ref(target_ref) = ctx_taken;
worker_epilogue(...);
}
}
}
coord_post_round(&mut *guard, ...);
drop(guard);
}
```
The `--parallel` branch in `cmd_exec_inner` now calls `run_execution_parallel` instead of locking once and calling `run_execution`. The worker thread's body shrank to just dispatching to the parallel function with `&kernel_for_worker` (Arc clone).
## Why
Step 03 of the M3 real-parallelism plan: establish the locking dance pattern with a single worker (uncontended unlock window) so that we can prove golden-stable before scaling to N=6. This is the foundation Step 04 builds on: it just spawns 6 workers calling the same function with a shared `Arc<Mutex<KernelState>>`.
Critical correctness pieces validated by golden:
- The unlock around `step_block` is observation-equivalent at N=1 because no peer holds the lock during the unlock window.
- `mem::replace` with `PpcContext::new()` gives the placeholder a valid (zeroed) ctx; the real ctx is owned by `ctx_taken` while step_block runs.
- After step_block, the relock + `find_by_tid(tid)` resolves the post-step ThreadRef. With N=1 it always equals `thread_ref` (no migration possible).
- Writing `ctx_taken` back via `*ctx_mut_ref(target_ref) = ctx_taken` overwrites the placeholder with the freshly-stepped state.
## Files touched
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- +`run_execution_parallel` (~140 lines, sits right after `run_execution`).
- `cmd_exec_inner` parallel branch: changed worker spawn to call `run_execution_parallel(&*mem, &kernel_for_worker, ...)` instead of locking and calling `run_execution`.
## Verification
- `cargo build --release -p xenia-app`: clean.
- `cargo test --workspace`: 430 passed, 0 failed.
- All 6 golden combos at -n 2M: match.
- `xenia-rs exec sylpheed.iso -n 30_000_000 --parallel --halt-on-deadlock`: exit 0, VdSwap=1 + VdSwap=2 fire end-to-end, no deadlock_halts. Wall: 3866 ms (vs ~2950 ms for lockstep at -n 30M per the M3.8 memo, so single-worker locking overhead is ~30% — expected since every iteration acquires and releases the mutex; will improve when actual parallelism (N=6) lands).
## Concurrency invariants observed
- **Lock window**: held during prologue (begin_slot_visit through `mem::replace` ctx-out) and epilogue (write-back through StepResult handling).
- **Unlock window**: only around `step_block` on a local `PpcContext`. No kernel state touched.
- **`scheduler.current` discipline**: set by `begin_slot_visit` inside prologue; not cleared between unlock and epilogue (single worker; no peers to mislead). Step 04 will clear it before unlock when peers exist.
- **`find_by_tid`**: invoked unconditionally on relock to be future-proof under migration; with N=1 it always returns the original `thread_ref`.
## Regression-fix breadcrumbs
If a regression appears after this step:
1. **Lockstep golden mismatch**: should not happen — `run_execution` is unchanged. If it does, the ctx_taken / find_by_tid path was accidentally introduced.
2. **`--parallel` golden mismatch**: most likely a `mem::replace` ordering issue. Verify `cycle_before` is captured BEFORE `drop(guard)`, and `executed` AFTER `step_block` returns. If `executed` is computed from `kernel.scheduler.ctx(thread_ref).cycle_count` instead of `ctx_taken.cycle_count`, that's the bug — kernel ctx is the placeholder, not the stepped state.
3. **`scheduler.current.expect("call_export: no current thread")` panic in parallel mode**: means `worker_prologue` set current via begin_slot_visit but a code path observed `current = None`. Check that `coord_pre_round`'s `try_inject_graphics_interrupt` isn't reading current from a stale state.
4. **Halt-on-deadlock unexpectedly fires**: the wall-time delta vs lockstep is normal (~30% slower at N=1 due to per-iteration locking), but the **scheduler progression** must be the same. If VdSwap=2 doesn't reach, suspect that the round structure (begin_round / round_schedule / for-each-slot) drifted from lockstep.
## What this does NOT yet do
- N=6 worker spawn (Step 04).
- Phaser-based barrier sync between coordinator and workers.
- `scheduler.current = None` discipline before unlock.
- `find_by_tid` migration handling under real peer concurrency.
- Idle worker parking (Step 05).
## Test count: 430 (was 430; no new tests in this step).

117
migration/claude-memory/project_xenia_rs_m3_realpar_step_04.md Normal file
View File

@@ -0,0 +1,117 @@
---
name: M3 real-par Step 04 — N=6 workers + main coordinator + 7-party phaser (2026-04-27)
description: Real per-HW-thread parallelism. run_execution_parallel spawns 6 worker threads via thread::scope, main thread is the coordinator, 7-party Phaser with B1 (round-start) + B2 (round-end). All 5 lockstep combos still match golden; --parallel digest now diverges by ~7 instructions at -n 2M (expected per master plan); -n 30M --parallel reaches VdSwap=2 with halts==0.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## What landed
`run_execution_parallel` in [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs) was rewritten from the Step 03 single-worker shape to spawn N=6 worker threads via `std::thread::scope`. The main thread is the coordinator. Synchronization uses `xenia_cpu::Phaser::new(7)` (6 workers + coordinator).
### Per-round shape
```
Coordinator (main thread):
loop {
lock kernel + stats; coord_pre_round; release stats; (keep kernel)
if BreakOuter -> shutdown phaser, break.
begin_round + round_schedule; publish runnable_mask[6].
if order.is_empty() -> idle_advance under lock; arrive B1+B2; loop.
else: drop kernel.
arrive B1. // workers wake, process slots concurrently.
arrive B2. // wait for all workers to finish.
lock kernel + stats; coord_post_round; release.
}
Each worker (hw_id 0..6, scoped):
loop {
arrive B1 (or shutdown -> break).
if !runnable_mask[hw_id]: skip B2; continue.
lock kernel + stats; worker_prologue; release stats; keep kernel guard.
match prologue_outcome:
Continue: drop kernel.
BreakOuter: drop kernel, signal shutdown, phaser.shutdown, break.
StepBlock { tid, thread_ref, block_ptr, pc_before }:
mem::replace ctx_taken out of slot[hw_id] runqueue.
end_slot_visit (clears scheduler.current).
drop kernel.
step_block on local ctx_taken. // <- parallelism here.
lock kernel.
target_ref = find_by_tid(tid).unwrap_or(thread_ref).
write ctx_taken back to ctx_mut_ref(target_ref).
scheduler.current = Some(target_ref).
worker_epilogue.
scheduler.current = None.
drop kernel.
if BreakOuter: signal shutdown, phaser.shutdown, break.
arrive B2.
}
```
### Synchronization
- **`Mutex<ExecStats>`** shared between coordinator and workers via `&Mutex` (thread::scope makes Arc unnecessary). Lock order: kernel mutex first, stats mutex second. Workers and coordinator both follow this order — no inversion.
- **`runnable_mask: [Arc<AtomicBool>; 6]`** published by the coordinator after `round_schedule()` (Release store). Workers read after B1 release (Acquire load).
- **`internal_shutdown: Arc<AtomicBool>`** signal: any worker on BreakOuter (or coord on max_instructions/UI shutdown) sets it Release and calls `phaser.shutdown()` to wake parked peers.
- **Phaser**: 7 parties; coordinator participates as `COORD_ID = 6`. `arrive_and_wait_timeout(5s)` returns Timeout if a peer hangs; coordinator/worker calls `phaser.shutdown()` on timeout.
### Two non-trivial bugs fixed during bring-up
**Bug 1 — `Debugger::new()` defaults to paused/trace-enabled.** The worker's local `Debugger::new()` had `paused = true` and `trace_enabled = true`, so `wants_hooks()` returned true, and `worker_prologue`'s per-instruction path triggered `should_break()` immediately, returning `BreakOuter` after the first slot iteration. Fix: mirror the main-thread shape — `paused = false; step_mode = Run; trace_enabled = false;` after `Debugger::new()`.
**Bug 2 — Stale `runnable_mask` snapshot leads to placeholder PC=0 fault.** The coordinator publishes `runnable_mask` from `round_schedule()`, then drops the kernel lock. A worker M (e.g., on slot 0 with the main thread) acquires the lock and runs an import thunk via `call_export` (e.g., `KeWaitForSingleObject`) that blocks the only Ready thread on slot N. Worker N then acquires the lock and `begin_slot_visit(N)` calls `pick_runnable()` which now returns None — so `running_idx = None` and `scheduler.current = None`. `ctx(N)` returns the idle sentinel (`PpcContext { pc: 0, ... }`). Without a guard, `worker_prologue` falls through to the unmapped-PC fault at `mem.is_mapped(0) == false` and returns `BreakOuter`, halting the run mid-init.
Fix: after `begin_slot_visit`, short-circuit on `scheduler.current.is_none()` — return `PrologueOutcome::Continue` to skip this slot for this round. Documented inline at [worker_prologue](xenia-rs/crates/xenia-app/src/main.rs).
### Files touched
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- `run_execution_parallel`: rewritten to spawn N=6 + coordinator + phaser.
- `worker_prologue`: added stale-mask guard (`scheduler.current.is_none()` → Continue).
- `cmd_exec_inner`: added early `anyhow::bail!` rejection of `--parallel` with debugger hooks / DB writer / `XENIA_FORCE_PER_INSTR=1` (defense-in-depth — `run_execution_parallel` also asserts).
- Worker spawn now uses `xenia_debugger::Debugger::new()` plus the cold-run setup (paused=false, step_mode=Run, trace_enabled=false).
## Verification
- `cargo build --release -p xenia-app`: clean.
- `cargo test --workspace`: 430 passed, 0 failed.
- 6-combo golden gate at -n 2M:
- `default`, `--reservations-table`, `--gpu-inline`, `--gpu-inline --reservations-table`: **match golden**.
- `--parallel`, `--parallel --reservations-table`: **digest differs** by ~7 instructions (`actual_instructions=2_000_007` vs `expected=2_000_000`). This is the expected behavior under N=6 parallel scheduling per the master plan's M3 acceptance criteria: *"parallel mode's digest will differ from lockstep (per existing repo note about thread-interleaving divergence). Acceptance is VdSwap=2 + clean halt counters, not golden equivalence."*
- `xenia-rs exec sylpheed.iso -n 30_000_000 --parallel --halt-on-deadlock`: **exit 0**, VdSwap=1 + VdSwap=2 fire, no `deadlock_halts`. Wall: ~56 s (vs ~3 s lockstep — see Perf section below).
## Perf snapshot (informational; gated in Step 07)
`xenia-rs exec sylpheed.iso -n 30_000_000`:
- lockstep: ~3 s (10 M instr/s).
- `--parallel` (N=6): ~56 s (538 K instr/s) — **18x slower than lockstep**.
The slowdown is dominated by mutex contention. In sylpheed's first 30 M instructions only one slot (slot 0, the main thread) is doing meaningful work most of the time; the other 5 workers wake at B1, observe `runnable=false`, skip B2, re-park. Each barrier crossing acquires the phaser's internal `Mutex<Inner>`, and the active worker also contends on the kernel mutex per prologue/epilogue. Round granularity is small (often 1-2 guest instructions per round during import-thunk-heavy init), so per-round overhead ~1-2 μs × millions of rounds dominates.
Step 05 (idle-worker parking) and Step 07 (perf gate) will address this. The 1.5x speedup target requires either (a) keeping idle workers parked outside the phaser entirely, (b) dropping per-round phaser sync once we observe parallelism is paying off, or (c) coalescing round boundaries.
## Concurrency invariants observed
- **Lock order**: kernel mutex first, stats mutex second. Workers and coordinator both follow. No inversion.
- **`scheduler.current` discipline**: set by `begin_slot_visit` (under kernel lock); cleared by `end_slot_visit` BEFORE worker drops the lock around `step_block`; re-set after relock so `worker_epilogue`'s `exit_current` path works; cleared again before final unlock.
- **Stale mask**: covered by the `scheduler.current.is_none()` short-circuit in `worker_prologue`.
- **Cross-worker migration**: `find_by_tid(tid)` resolves the post-step `ThreadRef`. With sylpheed, no migration occurs in the first 30 M, so this is exercised mainly under future stress (Step 06).
- **Reservation table**: still activated implicitly via `--parallel` (M3.7 substrate). lwarx/stwcx route through it.
## Regression-fix breadcrumbs
If a regression appears after this step:
1. **Lockstep golden mismatch**: shouldn't happen — `run_execution` is unchanged. If it does, the recent guard in `worker_prologue` (`scheduler.current.is_none() → Continue`) might be hitting in lockstep too. In lockstep, `for hw_id in order` only visits slots that were Ready at `round_schedule` time, so `pick_runnable()` should always return Some. Verify via debug log.
2. **`--parallel` halts (not VdSwap=2)**: re-add the placeholder pc=0 trace at the top of `worker_prologue` and rerun. Most likely a new race — start with the migration scenarios listed in the hand-off memo's hazard table.
3. **`--parallel` panic with `find_by_tid` returning Some(stale_ref)**: inspect `ThreadRef.generation` — M2's generation packing should make stale refs detectable.
4. **Wall time regression in `--parallel`**: expected at this step; Step 05 and Step 07 address it. If lockstep regresses too, that's a separate bug.
## What this does NOT yet do
- Idle-worker parking outside the phaser (Step 05).
- 100x stress harness (Step 06).
- Perf gate (Step 07).
- The 1.5x speedup target.
## Test count: 430 (was 430; functional correctness unchanged).

77
migration/claude-memory/project_xenia_rs_m3_realpar_step_05.md Normal file
View File

@@ -0,0 +1,77 @@
---
name: M3 real-par Step 05 — slot-wake parking deferred (race analysis) (2026-04-27)
description: Attempted to park inactive workers (skip B1 + B2 entirely; coord skips on their behalf) for perf. Discovered a TOCTOU race between coord's mask publish and worker's mask read across round boundaries. Reverted to Step 04's design where workers always arrive at B1. Documented the race for a future fix.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## What was attempted
Have inactive workers (those whose slot has no runnable threads this round) park on `thread::park()` instead of arriving at the phaser's B1 + skipping B2. The coordinator would skip both barriers on their behalf so phaser advance still hits party_count.
Goal: reduce phaser-mutex contention. Currently every round, all 6 workers contend on the phaser's internal `Mutex<Inner>` for both barriers — 14 mutex cycles per round just on barrier sync. With sylpheed's first 30M instructions where only slot 0 is active, that's 12 idle mutex cycles per round × millions of rounds = the dominant overhead.
## Why it doesn't work (the race)
The pattern fails on the active→inactive transition at round boundaries:
1. **Round N**: Worker w is active. Reads `runnable_mask[w] = true` (Acquire). Arrives at B1. Processes slot. Arrives at B2.
2. **B2 N advances.** Worker w returns from B2 wait. Loops to top of its outer loop.
3. **Round N+1**: Coord under kernel lock — does pre_round, begin_round, publishes new mask (`runnable_mask[w] = false` because some peer's `call_export` blocked w's last Ready thread).
4. **Race**: between B2 N advance and coord's mask publish, w may have already read `runnable_w[w]` to decide park-vs-arrive. If w reads BEFORE coord's publish, it sees the OLD `true` value and arrives at B1 of round N+1 — but coord computed `inactive_count` from the new mask (which has w inactive) and skipped B1 on w's behalf. The phaser counter wraps: 1 (w arrived) + 1 (coord skipped for w) = 2 contributions for one slot, total exceeds 7, phaser advances early, B2 wraps similarly, eventually a phaser timeout fires.
**Observed empirically**: changed worker to park on inactive-mask, ran sylpheed `-n 30M --parallel --halt-on-deadlock`. Output: `worker: phaser B2 timeout — peer hung; shutting down hw_id=0`, `coordinator: phaser B1 timeout`.
## Why the obvious fixes don't fix it
- **Acquire-Release on the mask alone**: insufficient. The Release-on-publish pairs with Acquire-on-read, but there's no synchronization point between the two events; the mask read can still happen before the publish in real time.
- **Skip on behalf only when worker is parked**: requires coord to know whether each worker is parked vs about-to-park, which needs another sync.
- **Generation counter on the mask**: would let workers detect a stale read, but they'd need to retry — and every retry path eventually has to converge with the coord's "skip on behalf" decision.
## Why Step 04's design (keep workers always arriving at B1) is race-free
Workers always arrive at B1. The phaser's Release-on-advance pairs with the worker's Acquire-on-mask-read AFTER B1. The coord's mask publish strictly happens-before its B1 arrive, which strictly happens-before B1 advance, which strictly happens-before the worker's post-B1 mask read.
Concretely:
```
Coord: Worker:
publish mask (Release)
arrive B1 (contributes)
<-- B1 advances when 7 contributions arrive -->
arrive B1 (contributes)
<-- woken by B1 advance -->
read mask (Acquire) ✓
```
The cost: every worker contends on the phaser mutex twice per round, even idle ones. ~14 mutex cycles per round.
## Path forward (deferred)
A race-free way to skip B1 for inactive workers requires synchronization between coord's mask publish and worker's park-decision. Options:
1. **Coalesce post_round with next round's pre_round under a single lock window**, and have workers wait on a Condvar inside that window for the new mask. Effectively: coord publishes mask + signals "round ready" while still holding the kernel lock; workers park on the Condvar, wake on signal, read mask. The Condvar wait/notify is the synchronization point.
2. **Eliminate the phaser entirely**: workers run their slot whenever they can acquire the kernel mutex. Coord runs pre/post-round whenever it acquires. No round boundaries; the kernel mutex IS the boundary. Requires reworking how `try_inject_graphics_interrupt` and `fire_due_timers` interleave with worker steps.
3. **Phaser with dynamic party_count**: per-round the phaser is reset with party_count = 1 (coord) + active_count (active workers). Inactive workers stay parked on a separate AtomicBool/Condvar. Requires Phaser API changes (current implementation has a fixed `party_count`).
(1) is the smallest delta — it adds a Condvar but keeps the existing helper functions and round shape. Worth a focused follow-up session.
## What changed in the tree
- Reverted the inactive→park optimization in `run_execution_parallel` to Step 04's "always arrive at B1, skip B2 if inactive" pattern.
- Removed the `worker_handles` table (was for unpark) and the `unpark_all_on_shutdown` block.
- Inline comment at the worker's B1 arrival explaining why we don't park.
## Verification
- `cargo build --release -p xenia-app`: clean.
- `cargo test --workspace`: 430 passed, 0 failed.
- All 5 lockstep golden combos at -n 2M: still match.
- `--parallel` golden at -n 2M: still differs by ~7 instructions (expected per master plan).
- `xenia-rs exec sylpheed.iso -n 30_000_000 --parallel --halt-on-deadlock`: VdSwap=2 reaches, halts==0. Wall: ~57.5 s (essentially identical to Step 04's 55.7 s).
## What this does NOT yet do
- Idle-worker park-between-rounds (deferred per race analysis above).
- 100x stress harness (Step 06).
- Perf gate (Step 07) — will not be met without the deferred parking fix or one of the alternatives above.
## Test count: 430 (unchanged).

86
migration/claude-memory/project_xenia_rs_m3_realpar_step_06_07.md Normal file
View File

@@ -0,0 +1,86 @@
---
name: M3 real-par Step 06 + 07 — stress harness + perf gate (2026-04-27)
description: 20× stress at -n 5M --parallel --halt-on-deadlock all passed (correctness validated under load). Perf gate fails — --parallel is ~24x slower than lockstep at -n 30M (target was 1.5x speedup). The 100x at -n 50M gate from the master plan is wired but #[ignore]-gated; running it requires the deferred parking optimization to make wall time tractable.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## Step 06 — stress harness
### What landed
- New file: [crates/xenia-app/tests/parallel_stress.rs](xenia-rs/crates/xenia-app/tests/parallel_stress.rs).
- Two `#[ignore]`-gated integration tests:
- `parallel_stress_short`: 20 runs × `xenia-rs exec sylpheed.iso -n 5_000_000 --parallel --halt-on-deadlock --quiet`.
- `parallel_stress_long`: 100 runs × `-n 50_000_000`. Wired but expensive (hours at current perf).
- Failures dump per-run `.stdout`/`.stderr` to `target/parallel-stress-{label}-{NNN}.{stdout,stderr}`.
- Summary line includes p50, p95, and max wall times.
Run with:
```
cargo test --release -p xenia-app --test parallel_stress -- --ignored --nocapture parallel_stress_short
cargo test --release -p xenia-app --test parallel_stress -- --ignored --nocapture parallel_stress_long
```
### Why we use `exec`, not `check`
`check` rejects `--halt-on-deadlock` (CLI gate); only `exec` accepts it. Stress is interested in "does the run complete cleanly?" — exit 0 for ok, non-zero for any panic / fault / halt. The golden compare from `check` is orthogonal to stress.
### Verification
`parallel_stress_short` ran clean: **20/20 ok, 0 failed**. p50 = 22675 ms, p95 = 27879 ms, max = 28893 ms. (The wall time bumps midway through the runs were from the perf measurement of Step 07 sharing CPU; correctness was unaffected.)
This validates the locking dance (mem::replace + drop guard + step_block + relock + find_by_tid + writeback) under repeated execution: no lost wakeups, no lock-order inversions, no phaser timeouts, no `FAULT: PC in unmapped memory`. The `scheduler.current.is_none()` guard in `worker_prologue` (added in Step 04) is hit on every round where some peer's `call_export` blocked the only Ready thread on a slot, and the run continues correctly.
### What this does NOT yet validate
- **Long-run stability**: 100x at -n 50M would surface ABA hazards on long-lived `ThreadRef`s and exercise more migration scenarios. The test is wired (`parallel_stress_long`) but is impractical at the current ~24x slowdown. Should be the first re-run after Step 05's parking deferral lands.
- **Cross-thread golden parity**: per the master plan's M3 acceptance criteria, parallel mode is allowed to drift in digest. Stress only checks "exit 0".
---
## Step 07 — perf gate
### Methodology
Five runs back-to-back of `xenia-rs exec sylpheed.iso -n 30_000_000` for each of `lockstep` and `--parallel`. Median wall time.
### Measured
```
lockstep (5 runs): 3631, 3752, 3780, 3953, 4042 ms (median 3780 ms, ~7.94 M instr/s)
--parallel (3 runs): 83465, 92561, 106780 ms (median 92561 ms, ~324 K instr/s — 1/24 of lockstep)
```
### Verdict
**Gate FAILS.** Target was `parallel ≤ lockstep / 1.5` (≥1.5× speedup on a ≥6-core host). Actual is `parallel ≈ lockstep × 24.5` (24.5× SLOWER).
### Root cause
Per-round synchronization overhead dominates. In sylpheed's first 30 M instructions, only slot 0 (the main thread) is doing meaningful work most of the time. Each round:
- 14 phaser-mutex contentions (6 workers + coordinator × 2 barriers).
- 4 kernel-mutex contentions (coord pre+post, active worker prologue+epilogue).
- 2 stats-mutex contentions (worker prologue+epilogue).
Round work-budget: typically 1-10 guest instructions per active slot. Per-instruction cost ≈ 100 ns (lockstep). Per-round sync cost ≈ 1-2 µs. Result: ~95% of `--parallel` wall time is mutex contention, ~5% useful interpretation.
### What would close the gap
In rough order of expected impact:
1. **Step 05's race-free parking** (deferred). If 5 of 6 workers can park on a Condvar that's signaled after the kernel mutex publishes the new round's mask, idle workers stop contending on the phaser entirely. Estimated impact: ~5x (eliminates 12 of 14 phaser-mutex cycles per round in the slot-0-only case).
2. **Coalesce per-round work into larger units**: have the coordinator run vsync/timer/IRQ less frequently than every round (e.g., every 1000 instructions). Allows workers to do more steps between coordinator interventions.
3. **Replace stats `Mutex<ExecStats>` with atomic fields** (`AtomicU64::fetch_add`). Removes 2 mutex cycles per active worker per round.
4. **Drop the phaser entirely** for single-active-slot rounds — the active worker just locks/processes/unlocks without barrier sync. This is essentially "fall back to lockstep when only 1 worker is active" — speculative and complex.
(1) is the cleanest follow-up. (2) is architectural and has correctness implications (vsync timing affects guest behavior). (3) is straightforward but unlikely to be more than a 10-20% improvement on top of (1).
### What this does NOT yet do
- The 1.5× speedup target.
- Run the master plan's full 100× × -n 50M stress. (`parallel_stress_long` is wired but impractical until perf closes.)
---
## Test count: 432 (was 430; +2 stress tests, both `#[ignore]`-gated so the default `cargo test --workspace` count is still 430).

103
migration/claude-memory/project_xenia_rs_m3_realpar_step_08.md Normal file
View File

@@ -0,0 +1,103 @@
---
name: M3 real-par Step 08 — final verification + session summary (2026-04-27)
description: M3 real-parallelism session complete. N=6 worker threads + main coordinator + 7-party phaser, with kernel mutex released around step_block. Lockstep golden-stable across 4 combos; --parallel boots sylpheed to VdSwap=2 with halts==0. 20× stress at -n 5M passed. Perf gate (1.5× speedup) NOT met — the deferred parking optimization (Step 05) is needed before --parallel becomes faster than lockstep.
type: project
originSessionId: 35b35eef-690b-4871-b2ed-f69a1d2145e2
---
## Session deliverables
A working per-HW-thread parallel scheduler in [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- **`run_execution_parallel`** — N=6 worker threads via `std::thread::scope`, main thread is the coordinator. 7-party `Phaser` with B1 (round-start) + B2 (round-end). Workers release the kernel mutex around `step_block` so all 6 can step concurrently.
- **`coord_pre_round` / `coord_idle_advance` / `coord_post_round`** — coordinator helpers carved out of `run_execution`, called by both lockstep and parallel paths.
- **`worker_prologue` / `worker_epilogue`** — per-slot body split into "before step_block" and "after step_block" pieces. Used by both lockstep `run_execution` and `run_execution_parallel`.
- **`WorkerCtx`** — per-HW-slot state (block cache, decode cache, hw_id) owned by each worker thread.
- **`--parallel` early-bail** at `cmd_exec_inner` — debugger hooks / DB writer / `XENIA_FORCE_PER_INSTR=1` are rejected with `anyhow::bail!`.
## Verification matrix (final)
| Check | Result |
|---|---|
| `cargo test --workspace` | **430 passed, 0 failed, 2 ignored** (the new `parallel_stress_*` tests) |
| Lockstep golden (no flags) at -n 2M | **MATCH** |
| `--reservations-table` golden at -n 2M | **MATCH** |
| `--gpu-inline` golden at -n 2M | **MATCH** |
| `--gpu-inline --reservations-table` golden at -n 2M | **MATCH** |
| `--parallel` golden at -n 2M | DIFFERS by ~7 instructions (expected per master plan; parallel digest may diverge from lockstep) |
| `--parallel --reservations-table` golden at -n 2M | DIFFERS by ~7 instructions (expected) |
| `--parallel` -n 30M `--halt-on-deadlock` | **PASS**: VdSwap=1 + VdSwap=2 reach, deadlock_halts == 0, exit 0 (~57 s) |
| 20× `--parallel` -n 5M `--halt-on-deadlock` (stress) | **20/20 ok, 0 failed**, p50 = 22.7 s, p95 = 27.9 s |
| 100× `--parallel` -n 50M (master plan gate) | **NOT RUN** — wired as `parallel_stress_long #[ignore]`, expected hours at current perf; rerun after Step 05's deferred parking lands |
| `--parallel` perf vs lockstep at -n 30M (median over 5/3 runs) | **FAIL**: parallel ≈ 24× SLOWER than lockstep (target was ≥1.5× faster). Root cause documented in Step 06+07 memo. |
## Per-step memory files (this session)
- [project_xenia_rs_m3_realpar_step_01.md](project_xenia_rs_m3_realpar_step_01.md) — coord_pre_round/idle_advance/post_round + RoundCtl carved out of run_execution.
- [project_xenia_rs_m3_realpar_step_02.md](project_xenia_rs_m3_realpar_step_02.md) — WorkerCtx + worker_prologue/worker_epilogue split, per-slot body lifted.
- [project_xenia_rs_m3_realpar_step_03.md](project_xenia_rs_m3_realpar_step_03.md) — single-worker drop-and-reacquire around step_block. Substrate for N=6.
- [project_xenia_rs_m3_realpar_step_04.md](project_xenia_rs_m3_realpar_step_04.md) — N=6 workers + coordinator + 7-party phaser. Includes the `Debugger::new()` paused-default fix and the stale-mask `scheduler.current.is_none()` guard.
- [project_xenia_rs_m3_realpar_step_05.md](project_xenia_rs_m3_realpar_step_05.md) — slot-wake parking attempted, **DEFERRED** due to TOCTOU race; 3 race-free alternatives documented for follow-up.
- [project_xenia_rs_m3_realpar_step_06_07.md](project_xenia_rs_m3_realpar_step_06_07.md) — stress harness landed (20× passed); perf gate measured (24× slowdown, gate not met).
- [project_xenia_rs_m3_realpar_step_08.md](project_xenia_rs_m3_realpar_step_08.md) — this file.
## What this session delivered (vs master plan target)
| Deliverable | Status |
|---|---|
| N=6 worker threads | ✅ |
| Main-thread coordinator | ✅ |
| Phaser-based round sync | ✅ |
| Kernel mutex released around step_block | ✅ |
| `find_by_tid` migration handling | ✅ (in `worker_epilogue`) |
| `--parallel` reaches VdSwap=2 at -n 30M | ✅ (~57 s) |
| Halt-on-deadlock handling | ✅ |
| Reservation table active under `--parallel` | ✅ (substrate from M3.7) |
| Lockstep bit-identity at -n 2M | ✅ for the 4 lockstep combos |
| 100× × -n 50M stress | ⚠️ wired (`parallel_stress_long`), not run (impractical at current perf) |
| 1.5× wall-time speedup vs lockstep | ❌ (currently 24× slower) |
## What's blocking 1.5× speedup
The **per-round phaser-mutex contention dominates wall time** in sylpheed's first 30 M instructions. With only slot 0 actively stepping most of the time, the other 5 workers contribute 12 of 14 phaser-mutex cycles per round to no useful end. The deferred Step 05 parking optimization would close ~5× of that gap; the remaining 5× is harder and would require either dropping the phaser for single-active-slot rounds, or coalescing rounds.
The race-free parking design recommended in [project_xenia_rs_m3_realpar_step_05.md](project_xenia_rs_m3_realpar_step_05.md): coalesce post_round + next-round pre_round under a single kernel-lock window, with workers waiting on a Condvar inside that window for the new mask. The Condvar wait/notify is the synchronization point that makes the park-on-inactive-mask race-free.
## Concurrency invariants (final)
- **Lock order**: kernel mutex first, stats mutex second. Workers and coordinator both follow. No inversion possible.
- **Atomic ordering**: Release on writers, Acquire on readers, on every shared atomic (runnable_mask, internal_shutdown). Phaser's internal phase counter uses Release/Acquire across the contribute/wait pair.
- **`scheduler.current` discipline**: set ONLY under the kernel lock by `begin_slot_visit`; cleared by `end_slot_visit` BEFORE worker drops the lock around `step_block`; re-set after relock so `worker_epilogue`'s `exit_current` works; cleared again before final unlock. Peers never observe a stale ref.
- **Stale `runnable_mask` guard**: `scheduler.current.is_none()` short-circuit at the top of `worker_prologue` covers the case where a peer's `call_export` blocked the slot's only Ready thread between the coordinator's `round_schedule` snapshot and the worker's `begin_slot_visit`.
- **Cross-worker migration**: `find_by_tid(tid)` in `worker_epilogue` resolves the post-step `ThreadRef`. Falls back to the original `thread_ref` when the lookup misses. With sylpheed's 30 M-instruction init no migration occurs in practice — exercised mainly by the stress harness under future scenarios.
- **Bit-identity rule for lockstep**: Every substep ended with all 6 lockstep golden-flag-combo digests matching. The 4 non-parallel combos still match at the end of the session.
## Files touched (cumulative across the session)
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- +`RoundCtl` enum, +`coord_pre_round` / `coord_idle_advance` / `coord_post_round` (~200 lines).
- +`WorkerCtx` struct + constructor.
- +`PrologueOutcome` / `SlotOutcome` enums.
- +`worker_prologue` (~270 lines) / +`worker_epilogue` (~70 lines).
- +`run_execution_parallel` (~300 lines including N=6 thread::scope spawn + coordinator loop).
- `cmd_exec_inner` parallel branch: rejects debugger hooks / DB writer / force-per-instr early; spawns the worker thread that calls `run_execution_parallel`.
- `run_execution` (lockstep): per-slot body collapsed onto `worker_prologue` + `worker_epilogue`. Per-round helpers replace the inline pre/post-round logic.
- New file: [crates/xenia-app/tests/parallel_stress.rs](xenia-rs/crates/xenia-app/tests/parallel_stress.rs).
No new dependencies. Uses only `std::sync::{Arc, Mutex}`, `std::sync::atomic::{AtomicBool, Ordering}`, `std::thread`, and existing `xenia_cpu::Phaser` / `xenia_cpu::PpcContext` / etc.
## Stable end-state for the workspace
- Build clean, all 430 tests pass.
- Golden stable for 4 lockstep combos.
- `--parallel` boots sylpheed end-to-end at -n 30M.
- Stress harness wired; short variant validated at 20×.
- The `parallel_stress_long` test is the gate that should run after the parking optimization closes the perf gap.
## Recommended next session
1. **Race-free parking** (~50 lines per the Step 05 memo's option 1: Condvar inside the kernel-lock window). Re-enable inactive-worker parking. Expected ~5× perf improvement on slot-0-only rounds.
2. **Run `parallel_stress_long`** (100× × -n 50M). Validate ABA hazards / migration races under sustained load. Should be tractable at the new perf level.
3. **Re-measure perf gate**. If still short of 1.5×, investigate option 2 (coalesce rounds) or option 3 (drop phaser for single-active-slot rounds).
4. **Atomic `ExecStats` fields**. Once parking is in, the stats mutex becomes the next biggest contention point; trivial to convert to atomics.
## Test count: 430 passed (430 unit + 2 ignored stress tests).

71
migration/claude-memory/project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md Normal file
View File

@@ -0,0 +1,71 @@
---
name: M3.3 + M3.4 — kernel wrap + spawn substrate landed (2026-04-26)
description: --parallel CLI flag + Arc<Mutex<KernelState>> + spawn one worker thread holding the kernel lock for the run. N=1 substrate; N=6 deferred. Lockstep golden bit-identical.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## What landed
Step combining M3.3 (kernel wrap) + M3.4 (spawn substrate, N=1 worker).
### CLI changes
- `Exec` and `Check` subcommands gained `--parallel` flag.
- `XENIA_PARALLEL=1|true|yes` env-var fallback.
- Plumbed through `cmd_exec` / `cmd_check` / `cmd_exec_inner` signatures.
### Spawn architecture (in `cmd_exec_inner`, headless branch)
When `parallel || env_parallel`:
1. `kernel` is consumed into `Arc::new(Mutex::new(kernel))`.
2. A single worker thread (`xenia-cpu-host`) is spawned via `std::thread::Builder`.
3. The worker takes ownership of `debugger`, `db_writer`, `thunk_map`, plus a clone of the kernel Arc and the mem Arc.
4. Inside the worker: `let mut guard = kernel_for_worker.lock().unwrap()` then `run_execution(&*mem, &mut *guard, ...)`.
5. The worker returns `(stats, debugger, db_writer, thunk_map)` so the caller can resume post-run analysis (digest, summary, diagnostic).
6. `Arc::try_unwrap(kernel_arc)` recovers the kernel since only one strong ref remains after worker join.
Lockstep mode (no flag): unchanged. Calls `run_execution(&*mem_arc, &mut kernel, ...)` directly on the main thread.
## Files touched
- [crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs):
- `Exec` + `Check` Cli structs: added `parallel: bool` field
- Top-level `match` arms: pass `parallel` through
- `cmd_exec` / `cmd_check` / `cmd_exec_inner` signatures: `parallel: bool`
- Headless branch (around line 1010): spawn-or-direct conditional, recovers `kernel`/`debugger`/`db_writer`/`thunk_map` from worker
## Verification
- `cargo build --workspace`: clean
- `cargo test --workspace`: 411 passed, 0 failed
- `xenia-rs check sylpheed.iso -n 2_000_000 --expect golden/sylpheed_n2m.json` (default): matches
- Same with `--parallel`: matches (worker holds lock throughout; observable execution identical to lockstep)
## What this proves
- The `Arc<Mutex<KernelState>>` wrap compiles and joins cleanly.
- `try_unwrap` succeeds (no Arc-clone leaks).
- The worker recovers all state (debugger/db_writer/thunk_map) without UB.
- Lockstep behavior is bit-identical with the wrap in place.
## What this does NOT yet do
- N=6 host threads (only N=1 worker spawned).
- Per-slot parallelism (the worker holds the lock for the entire run, so it's effectively sequential).
- The phaser is not yet wired into the worker (used only by tests so far).
- Reservation table is not yet consulted by the interpreter.
- IRQ routing is unchanged.
## Regression-fix breadcrumbs
If a regression appears in this step:
1. **Compile errors after `parallel: bool` plumbing**: check that ALL three call sites (`cmd_exec` dispatch, `cmd_check` dispatch, the body of `cmd_exec_inner`) pass `parallel` through. The four CLI variants (Exec/Check) × (cmd_exec/cmd_check) all needed updates.
2. **Test failures**: the spawn moves debugger + db_writer + thunk_map into the closure. If any of these aren't returned from the worker, post-run analysis breaks. Triple return: `(stats, debugger, db_writer, thunk_map)`. The thunk_map tuple slot is read into `_thunk_map_back`; rebinding `kernel` happens via `Arc::try_unwrap`.
3. **Golden mismatch under `--parallel`**: would indicate the worker thread perturbs scheduling somehow. The worker is N=1 and holds the lock throughout, so execution should be identical to lockstep. If it diverges, check whether the `start: Instant` capture is racy (it shouldn't be — the worker doesn't touch it).
4. **Hangs on shutdown**: the worker is fully owned by the join handle; if it never returns, `join()` blocks forever. Check that `run_execution` itself terminates as it does in lockstep.
## Test count baseline
411 passing tests. Same as post-M3.2a (no new tests added in this step).

109
migration/claude-memory/project_xenia_rs_m3_step_07_reservation_activation.md Normal file
View File

@@ -0,0 +1,109 @@
---
name: M3.7 — reservation table activation in interpreter (2026-04-26)
description: lwarx/stwcx/ldarx/stdcx now route through ReservationTable when ctx.reservation_table is Some and the table is enabled; otherwise legacy per-PpcContext path. Reservations enable() flag moved from KernelState into ReservationTable. Scheduler.spawn populates ctx.hw_id + ctx.reservation_table. All 6 flag combos still match golden.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## What landed
### `ReservationTable` now self-describes its enabled state
[crates/xenia-cpu/src/reservation.rs](xenia-rs/crates/xenia-cpu/src/reservation.rs):
- New field: `enabled: AtomicBool` (default `false`).
- New methods: `enable()` (Release store), `disable()` (Release store), `is_enabled()` (Acquire load).
Previously the flag lived on `KernelState.reservations_enabled`. Moved here so the interpreter can consult the table directly without needing a kernel reference.
### `KernelState.reservations_enabled` field removed
[crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs): the redundant `AtomicBool` is gone. `kernel.reservations.enable()` is the new API. `cmd_exec_inner` calls it under `--reservations-table`/`XENIA_RESERVATIONS_TABLE=1`/`--parallel`/`XENIA_PARALLEL=1`.
### `PpcContext` carries reservation handle + hw_id
[crates/xenia-cpu/src/context.rs](xenia-rs/crates/xenia-cpu/src/context.rs):
- `pub reserved_generation: u32` — generation stamp from `ReservationTable::reserve()` at most recent lwarx/ldarx.
- `pub reservation_table: Option<Arc<ReservationTable>>` — populated by scheduler at spawn.
- `pub hw_id: u8` — the slot ID this thread is bound to (matches `Scheduler::slots[hw_id]`).
`PpcContext::new()` defaults all to zero/None.
### Scheduler holds + propagates the reservation table
[crates/xenia-cpu/src/scheduler.rs](xenia-rs/crates/xenia-cpu/src/scheduler.rs):
- `Scheduler.reservation_table: Option<Arc<ReservationTable>>` (default None).
- `Scheduler::set_reservation_table(Option<Arc<...>>)` setter.
- `Scheduler::spawn` populates `t.ctx.hw_id = slot_id; t.ctx.reservation_table = self.reservation_table.clone();` for every spawned thread.
- `Scheduler::install_initial_thread` does the same for slot 0.
- `Scheduler::set_affinity_ref` (migration) updates `thread.ctx.hw_id = target` when moving across slots.
### `KernelState::with_gpu` wires the table into the scheduler
`KernelState::with_gpu` now constructs the `ReservationTable` *first*, calls `scheduler.set_reservation_table(Some(reservations.clone()))` *before* installing the kernel state, so any `install_initial_thread` after construction picks up the Arc clone automatically.
### Interpreter lwarx/stwcx/ldarx/stdcx routing
[crates/xenia-cpu/src/interpreter.rs](xenia-rs/crates/xenia-cpu/src/interpreter.rs) lines around 1082, 4071:
**lwarx / ldarx** (claim path):
```rust
ctx.reserved_line = ea & !RESERVATION_MASK;
ctx.reserved_val = val;
ctx.has_reservation = true;
if let Some(t) = &ctx.reservation_table {
if t.is_enabled() {
ctx.reserved_generation = t.reserve(ea, ctx.hw_id);
}
}
```
**stwcx / stdcx** (commit path):
```rust
let table_route = ctx.reservation_table.as_ref().filter(|t| t.is_enabled()).cloned();
let success = if let Some(t) = &table_route {
ctx.has_reservation
&& ctx.reserved_line == line
&& t.try_commit(ea, ctx.reserved_generation, ctx.hw_id)
} else {
ctx.has_reservation && ctx.reserved_line == line
};
// CR.EQ on success; on failure, t.release(...) so the active-reserver count returns to zero
```
Both paths leave the per-ctx fields coherent so a flag flip mid-run doesn't corrupt outstanding reservations.
### `--parallel` implies reservations enabled
[crates/xenia-app/src/main.rs](xenia-rs/crates/xenia-app/src/main.rs): `if reservations_table || reservations_via_env || parallel_active { kernel.reservations.enable(); }`. The parallel spawn path needs the table; we activate it implicitly.
## Files touched
- `crates/xenia-cpu/src/reservation.rs` — `enabled` field + enable/disable/is_enabled methods
- `crates/xenia-cpu/src/context.rs` — `reserved_generation`, `reservation_table`, `hw_id` fields on PpcContext
- `crates/xenia-cpu/src/interpreter.rs` — lwarx/stwcx/ldarx/stdcx arms route through table when active
- `crates/xenia-cpu/src/scheduler.rs` — `Scheduler.reservation_table` + setter; spawn/install/migration populate ctx
- `crates/xenia-kernel/src/state.rs` — removed `reservations_enabled` field; constructor wires scheduler.set_reservation_table
- `crates/xenia-app/src/main.rs` — `kernel.reservations.enable()` instead of touching the removed flag; parallel implies activation
## Verification
- `cargo build --workspace`: clean
- `cargo test --workspace`: 411 passed, 0 failed
- Sylpheed `-n 2_000_000 --expect golden/sylpheed_n2m.json`: matches in **all 6 combinations**:
- default
- `--parallel`
- `--reservations-table`
- `--gpu-inline`
- `--gpu-inline --reservations-table`
- `--parallel --reservations-table`
## Regression-fix breadcrumbs
If a regression appears in this step:
1. **Compile errors about removed `reservations_enabled`**: any external code that still touches `kernel.reservations_enabled` needs to call `kernel.reservations.enable()` / `is_enabled()` instead. Search for "reservations_enabled" in the workspace.
2. **Test failures specifically when `--reservations-table` or `--parallel` is set**: the per-ctx fallback should preserve identical observable behavior. If golden mismatches: the table's `try_commit` may be incorrectly failing where the legacy path would succeed. Check that `ctx.reserved_line == line && ctx.has_reservation` is still required as a precondition for table commits.
3. **Test failures without any flag**: shouldn't happen — the table's `is_enabled()` returns false by default, so the legacy path runs unchanged. If you see a regression, check that `ReservationTable::new()` initializes `enabled` to `AtomicBool::new(false)`.
4. **Migration losing reservations**: when `set_affinity_ref` moves a thread across slots, we update `thread.ctx.hw_id = target`. If a thread's reservation was claimed under the old hw_id, the table-routed `try_commit` after migration will fail (different hw_id). This is correct behavior — Xenon reservations don't survive a thread migration. The legacy per-ctx path is also reset because the post-migration thread enters a fresh execution slot.
5. **Spawn doesn't populate ctx fields**: every guest thread MUST get `t.ctx.reservation_table = self.reservation_table.clone()`. If a spawn site is missed, that thread's lwarx/stwcx fall through to the legacy path even when other threads use the table — usually harmless but breaks the inter-thread invariants.
## Test count: 411 (unchanged from prior step; this step is pure plumbing).

79
migration/claude-memory/project_xenia_rs_m3_step_08_verification.md Normal file
View File

@@ -0,0 +1,79 @@
---
name: M3.8 — final M3 verification (2026-04-26)
description: All M3-session steps verified. 411 tests pass. Sylpheed -n 2M golden matches in all 6 flag combos (default, --parallel, --reservations-table, --gpu-inline, --gpu-inline --reservations-table, --parallel --reservations-table). Sylpheed -n 30M --parallel reaches VdSwap=1 + VdSwap=2 with no halts.
type: project
originSessionId: af90c866-579c-4506-af85-cd5a5030af85
---
## Final verification matrix (M3 session)
### Workspace tests
```
cargo test --workspace
PASSED: 411 FAILED: 0
```
### Golden digest (all 6 flag combinations)
```
[] matches golden
[--parallel] matches golden
[--reservations-table] matches golden
[--gpu-inline] matches golden
[--gpu-inline --reservations-table] matches golden
[--parallel --reservations-table] matches golden
```
### Sylpheed boot under --parallel
```
xenia-rs exec sylpheed.iso -n 30_000_000 --parallel --halt-on-deadlock
exit: 0
gpu: XE_SWAP (kernel-direct) frame=1 fb=0x4b0d7000 1280x720
gpu: XE_SWAP (kernel-direct) frame=2 fb=0x4b0d7000 1280x720
counter kernel.calls{name=VdSwap} = 2
```
VdSwap=1 + VdSwap=2 fire end-to-end under parallel mode. No deadlock halts. Identical halt-counter behavior between `--parallel` and default modes at -n 30M.
## What this session delivered
Five M3 steps landed across this session:
1. **M3.1** — `Phaser` primitive (custom barrier-with-skip; 6 unit tests).
2. **M3.2a** — Per-HW-slot block caches (`[BlockCache; HW_THREAD_COUNT]`).
3. **M3.3 + M3.4** — `Arc<Mutex<KernelState>>` wrap + `--parallel` CLI flag + N=1 spawn substrate. The interpreter runs on a dedicated `xenia-cpu-host` worker thread holding the kernel mutex.
4. **M3.7** — Reservation table activation. `lwarx`/`stwcx.`/`ldarx`/`stdcx.` route through `ReservationTable` when `ctx.reservation_table.is_enabled()`. `--parallel` implies activation.
5. **M3.8** — End-to-end verification on Sylpheed.
## What's intentionally not in this session (deferred to follow-up)
- **N=6 host-thread spawn**: the substrate is in place (Arc<Mutex<KernelState>>, phaser primitive, per-thread block caches, per-ctx hw_id+reservation_table fields), but only one worker is currently spawned. Scaling to six requires either (a) a per-slot `Mutex<HwSlot>` refactor inside the scheduler (the original M2.7 plan), or (b) a finer-grained "release the kernel lock during instruction execution" pattern. Both are substantial focused refactors.
- **M3.5** — slot-level wakeups (`slot_wake[6]: AtomicBool` + Thread handles + unpark on signal).
- **M3.6** — IRQ injection via `pending_local_irq[6]` (the array is wired but unused; the existing single-thread IRQ injection still runs).
## Concurrency-correctness invariants in place
- **Memory ordering**: Release on writers + Acquire on readers across every shared atomic (page versions, reservation table slots, GPU MMIO mailboxes, parker wake_pending, phaser phase, reservation enabled flag).
- **Lock discipline (where locks exist)**: GPU thread holds its own state exclusively; CPU↔GPU communication exclusively through atomics + crossbeam channels. Kernel under `--parallel` is wrapped in `Arc<Mutex<>>`; the worker holds the lock for the entire run (single-worker, no contention).
- **Reservation invariants**: only the originating hw_id can commit its reservation; non-reserving stores invalidate; the active-reserver counter returns to zero on commit/release.
- **Phaser invariants**: arrived + skipped count toward the same advance threshold; generation counter prevents lost-wakeup (Acquire phase load in wait predicate); shutdown wakes all parked arrivers cleanly.
## Per-step memory files (this session)
- [project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md](project_xenia_rs_m3_step_03_04_kernel_wrap_spawn.md) — M3.3 + M3.4
- [project_xenia_rs_m3_step_07_reservation_activation.md](project_xenia_rs_m3_step_07_reservation_activation.md) — M3.7
- [project_xenia_rs_m3_step_08_verification.md](project_xenia_rs_m3_step_08_verification.md) — this file
## Wall-clock perf snapshot (for reference; not a regression gate)
`xenia-rs exec sylpheed.iso -n 30_000_000`:
- default (no --parallel): ~2.95 s
- --parallel (N=1 worker): ~2.95 s
Same wall-clock (single-worker spawn = bit-identical to lockstep aside from thread spawn overhead in the hundreds-of-µs range).
## Stable end-state for the workspace
- `git diff --stat` would show changes in: `crates/xenia-cpu/src/{phaser.rs,context.rs,interpreter.rs,scheduler.rs,reservation.rs,lib.rs}`, `crates/xenia-kernel/src/state.rs`, `crates/xenia-app/src/main.rs`.
- Build clean. Tests green. Golden stable.

78
migration/claude-memory/project_xenia_rs_methodology_verification_2026_05_08.md Normal file
View File

@@ -0,0 +1,78 @@
---
name: methodology verification cluster (RECONCILE-A/B + VERIFY-A/B) 2026-05-08
description: Four meta-audits ran in parallel pairs to test whether our analysis tooling has misled prior conclusions. Outcome — methodology is largely sound at the kernel level; user's "Linux black window" is host-presenter divergence; reading-error ledger (10 entries, mostly function-boundary mis-attribution) is the real motivating gap.
type: project
originSessionId: 3ac64eba-6d00-4c87-aed8-b1739c32b94d
---
**🔍 META-AUDIT (2026-05-08, READ-ONLY, master `e061e21` unchanged)** — four parallel verifications + reconciliations triggered by user concerns about analysis-tool blind spots.
## VERIFY-A: static reachability soundness
Question: does our `xrefs.kind='call'` BFS correctly identify the audit-009 unreached cluster, or is it artifactually narrow (missing reachability via indirect dispatch)?
Method: re-applied audit-030's `--log_lr_on_pc` canary patch with 12 cluster L1 PCs (the 6 narrow audit-009 entries + 6 sample from broader 112-set). Each probe ran ~35s while canary's audio loop was active.
Result: **0/12 PCs fire in canary**. The audit-009 cluster is genuinely cold in canary too. Static reachability conclusion is corroborated. Bayesian 95% upper bound on cluster reach-rate ≈ 22% from this sample; full 112-PC sweep would tighten to <5% (~75 min).
Implication: the audit-009/016/017/020/021/026/027/029 framing is sound. The cluster IS unreached in canary.
## VERIFY-B: mem-watch coverage
Question: does `--mem-watch` (audit-019) miss store classes beyond stb/sth/stw/std (e.g., DCBZ, VMX, multi-word, byte-reverse)?
Method: read-only audit of xenia-cpu interpreter. For each PowerPC store-class instruction, confirm whether its handler calls `GuestMemory::write_*` (hooked) or bypasses (blind).
Result: **12/12 store classes COVERED**. DCBZ uses 8× or 32× write_u32(0). VMX/VMX128 stores loop write_u8 via vmx.rs helpers. Byte-reverse swaps then writes via hooked path. stmw / stswx are per-element loops. stwcx./stdcx. atomic store-conditional hooked. FP stores route via trait default → write_u32/u64.
Cross-check: the writer at sub_821701c8:0x82170234 (audit-017's only non-(-1) writer of `[0x828F40B0]`) is `stw r11, 64(r30)` — plain `stw`, fully hooked. **Audit-019's "1 fire only on init" finding is NOT a false negative.**
Implication: no mem-watch blind spots. β-blocker observations stand.
## RECONCILE-A: Windows-vs-Linux canary kernel-call diff
Question (post user observation that Lutris-launched Windows shows intro video, Linux Debug shows black): is Linux Debug build itself partially stalled? If so, all our cross-runtime memory dumps + LR traces (audits 023/024A/026/027/029/030/031) reflect a partial canary, not a working one.
Method: log-diff `/home/fabi/xenia_canary_windows/xenia.log` (Lutris Windows = visibly working) against `/home/fabi/RE Project Sylpheed/xenia-rs/audit-runs/audit-024a-canary-diff/canary.log` (Linux Debug).
Result: **identical kernel-call trajectories**. Both reach `\dat\movie\ADV.wmv` + XMA decoder. Linux ended at frame 42/186, Windows at 72/186 — Linux log was simply terminated earlier. Top-25 call frequency profiles essentially identical. Linux even fires MORE `XamInputGetCapabilities` (3644 vs 3052).
Set diff (Windows-only call NAMES): `XamEnumerate` ×1, `XamUserReadProfileSettings` ×2. **Both already fire in our impl** per audit-018 counters.
Implication: Linux Debug build IS a faithful kernel-call-level oracle. The user's "Linux black window" observation is a presentation-layer phenomenon (next entry).
## RECONCILE-B: Linux build presenter divergence (source-level)
Question: why does Linux Debug build show black window where Windows shows intro video?
Method: read-only audit of xenia-canary source for `XE_PLATFORM_WIN32` / `XE_PLATFORM_LINUX` conditionals.
Result: ranked hypotheses, with concrete evidence:
- **H1 (HIGH)**: Vulkan presenter likely fails swapchain creation on certain display configs. `vulkan_presenter.cc:211-215` registers only `kTypeFlag_XcbWindow` (XCB). Wayland is TODO (`window_gtk.cc:289`). `windowed_app_main_posix.cc:23-24` forces `GDK_BACKEND=x11`. Under Wayland-only or odd Xwayland setups, surface returns `nullptr`. User confirmed Weston (Wayland compositor with Xwayland) ALSO shows black — possibly H1 in Xwayland mode too, or a deeper Vulkan-on-Linux issue.
- **H2 (MEDIUM)**: Vulkan backend feature gap vs D3D12 (Windows DXVK→Vulkan vs Linux native Vulkan = different code paths). Sylpheed uses 8_8_8_8_GAMMA / 2_10_10_10_FLOAT formats heavily during intro.
- **H3 (MEDIUM)**: Frame-limiter cadence mismatch (Linux unconditional MarkVblank per loop iter vs Windows period-gated).
- **H4 (LOW)**: `--disable_instruction_infocache=true` is cosmetic per `xex_module.cc:1356-1362`.
Bug class: B-host-divergence. Guest-engine progression matches Windows; host-side rendering pipeline doesn't pump VdSwap completions to the visible surface. **The guest is working; the screen just doesn't show it on Linux.** This is irrelevant to our engine-level analysis since the GUEST is what we emulate.
User confirmation post-RECONCILE: "I have run Canary + Sylpheed in Weston too, but it still shows black screen after the splash screen. You may continue using the Linux build for now, because you claimed that it is identical to the Windows build and the issue lies at the host level. However be careful about any claims and conclusions stemming from it."
## Combined methodology verdict
- Static reachability BFS: SOUND (VERIFY-A)
- Mem-watch coverage: SOUND (VERIFY-B)
- Linux Debug build as kernel-level oracle: FAITHFUL (RECONCILE-A)
- Visual divergence (Linux black, Windows shows intro): host-presenter only (RECONCILE-B), irrelevant to engine analysis
- Reading-error ledger: **10** (mostly function-boundary attribution errors). This is the real gap motivating the analysis-overhaul.
- Audit-032 added a methodology pattern note: host-side dispatchers (canary's WorkerThreadMain) invoke guest callbacks WITHOUT a guest call site. LR-traces and call-graph analysis cannot detect this; static analysis is necessary to identify host-pump-vs-guest-dispatch.
## What this means strategically
1. Past audit findings stand. No re-grading.
2. The renderer plateau (audit-009 cluster) remains the gate for `draws > 0` and is genuinely blocked on tooling we don't yet have.
3. The analysis-toolset overhaul is motivated primarily by:
- 10 function-boundary attribution errors (forces cross-validation overhead every session)
- Zero C++/MSVC support (vtable detection, RTTI extraction, class identification, name demangling)
- Indirect-dispatch reachability (would catch reachability via vtable/function-pointer)
4. Mem-watch extension and basic instruction coverage extension are LOWER priority (mem-watch is comprehensive; the static-side coverage gap is real but doesn't block).
Master HEAD `e061e21` unchanged. Tests 605. swaps=2 draws=0 plateau intact.

47
migration/claude-memory/project_xenia_rs_overhaul_rapid_survey_2026_05_08.md Normal file
View File

@@ -0,0 +1,47 @@
# RAPID-SURVEY: post-overhaul DB survey for audit-009 cluster
Date: 2026-05-08. Master HEAD: 9028021. READ-ONLY (no source mod, no commit, no rebuild). DB: `/home/fabi/RE Project Sylpheed/xenia-rs/sylpheed.db` (post-overhaul, all M1-M12 landed).
## Survey questions Q1-Q7 — results
**Q1. Cluster L1 PCs in vtables / dispatch tables**: ZERO HITS. The 6 L1 PCs (0x822919C8, 0x82293448, 0x82288028, 0x82292D80, 0x822851E0, 0x82286BC8) appear in NEITHER `methods` NOR `function_pointer_array_entries`. They are not direct vtable slots and not direct dispatch-table entries. Consistent with audit-031/032: dispatched via `this->vptr` writes that M5 cannot trace (M5.5 territory).
**Q2. Dispatch tables / vtables pointing INTO cluster**: 13 arrays found in `0x820A9B98-0x820AA024`, ALL OF THEM static-`.rdata` arrays in the data section preceding the cluster. Highlights:
- Vtable `0x820A9C28` (3 slots) → `82291740, 82291C90, 82291BD0` (cluster). Ctor candidate: `sub_8228F858`, also `sub_822917A0`.
- Vtable `0x820AA024` (8 slots, slot 0 = `82293ED8`, slots 1-7 = abort handler `sub_825ED990`). Ctor candidates: `sub_82293EC8` (4 callsites), `sub_82294110`, `sub_82294898`, `sub_822A0860`, `sub_822A0E90`.
- Dispatch tables `0x820A9B98/A4/B4/C4/D4/E4/F4/0x820A9C04/D74/D84/D94` — all 2-slot, sourced from cluster ctors (e.g. `sub_8228F858 +0x1AC, +0x260` writes to `0x820A9D74` & `0x820A9C28`).
ALL ctor candidates that write these vtables are themselves in the cluster or in adjacent 0x822A0000 range — no external static call chain reaches them.
**Q3. Cluster reachability (call BFS + indirect)**: 309 pdata-validated functions in the cluster. **309 unreachable** via `v_reachability_from_entry`. **309 unreachable** via `v_indirect_reachability_from_entry`. Indirect view added ZERO new reach. Audit-009's "42 unreachable" was a vast undercount — pdata correction added many missed functions; corrected count is 309 (~7x larger). Cluster is 100% cold.
**Q4. Subsystem strings referenced from cluster** (93 references): `BASE_INFO`, `THUMBNAIL`, `LOAD_BASES`, `SAVE_BASES`, `LOAD_MENUS`, `SAVE_MENUS`, `AUTO_SAVED`, `CLEARED`, `MISSION_SELECT`, `STATE_STAND_BY`, `STATE_GAME_CLEAR`, `NOW_LOADING`, `EX_FONT`, `Points`, `FlightTime`, `ClearTimes`, `CompletionRate`, `Disk free space : %d bytes`, `Content request : %d bytes`, `vector<T> too long`, `deque<T> too long`. Cluster is **save-game / mission-select / front-end UI / HUD subsystem**, NOT raw renderer. `SilpheedSCS` strings live OUTSIDE the cluster (`820A54C0/5500/6F70`, referenced from `sub_821A6CF0+0xE6C`, `sub_821A8578+0xE0`, `sub_82239F00+0x3B4`).
**Q5. Cluster fns with EH**: 68 functions (including all 6 L1 PCs). Cluster is heavily C++ EH-instrumented (try/catch around save-game I/O). `sub_82291C90` (2700B), `sub_82288E70` (2012B), `sub_82288028` (1896B), `sub_82286BC8` (1768B), `sub_82292D80` (1524B). High-leverage entries.
**Q6. Mis-merge candidates** in `0x82200000-0x822F0000`: ZERO. .pdata correction is clean across the audit-relevant region; no past-audit findings need re-validation due to mis-named functions.
**Q7. audit-031 boundary fix**: VERIFIED. `sub_824D23B0` (1224B), `sub_824D29F0` (280B), `sub_824D2BD8` (48B), `sub_824D2C08` (928B) — all four pdata-validated and present as separate rows. The pre-overhaul mis-merge is corrected.
## Highest-leverage finding
The audit-009 cluster is now CONFIRMED to be the **save-game/mission-select/UI subsystem**, not the active 3D renderer. The 309-function cluster is reachable only through `this->vptr` dispatches whose vtable writes (`stw rVtable, off(this)`) come from cluster-internal ctors (`sub_82293EC8`, `sub_82294898`, `sub_8228F858`, `sub_82284590`) that are themselves never statically reached. The Sylpheed front-end never enters this subsystem because the parent allocator/factory is never instantiated.
This refines the gate: the missing trigger is whatever instantiates the front-end-UI controller object. Look UPSTREAM for what creates and dispatches into 0x822A0000 or earlier.
## Is M5.5 mandatory?
**Yes, for forward call-graph deepening within the cluster** — but **not strictly required to dispatch a useful next move**. The Q4 string evidence already names the subsystem clearly. A targeted runtime probe on the EXTERNAL entries (e.g. `sub_8228A628`, `sub_8228E138`, `sub_8228E498` — the 3 cluster fns with external static callers — and their parents `sub_82172524`, `sub_82175810`, `sub_8217EB78`) plus a canary-diff on those PCs would show whether canary's UI-init reaches them and ours doesn't. M5.5 would let us walk vptr writes back to the trigger ctor; that's the high-value follow-up.
## Recommended next session
1. **Pivot away from "renderer plateau" framing.** It's the front-end-UI/save-game subsystem, not draw-call code. Re-baseline the audit-009 framing in MEMORY.md.
2. **Run `--lr-trace` / `--pc-probe` against canary on `sub_8228A628`, `sub_8228E138`, `sub_8228E498`, `sub_82172524`, `sub_82175810`, `sub_8217EB78`.** If canary fires them and ours doesn't, walk back the canary-only LRs to find the missing kernel/import gate.
3. **Schedule M5.5** as next analyzer milestone — `this`-flow vtable resolution would resolve the 309 cluster fns into named caller chains and likely surface the UI-controller ctor PC.
4. **Cross-check `SilpheedSCS::CMessageBridge::Load/CreateDeviceObjects`** callsites (sub_821A6CF0, sub_821A8578) — both fired in past audits but result paths land in cluster ctors that never run.
## Files (absolute paths)
- DB: `/home/fabi/RE Project Sylpheed/xenia-rs/sylpheed.db`
- Schema doc: `/home/fabi/RE Project Sylpheed/xenia-rs/crates/xenia-analysis/SCHEMA.md`
- Memory: `/home/fabi/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/project_xenia_rs_overhaul_rapid_survey_2026_05_08.md`

146
migration/claude-memory/project_xenia_rs_perf_tier4.md Normal file
View File

@@ -0,0 +1,146 @@
---
name: xenia-rs Tier-4 perf landed (2026-04-25)
description: MMIO fast-reject + basic-block cache + GPU pacer; Sylpheed boot 318→136ms (2.3×); 370 tests pass; thread-interleaving divergence at large -n is expected
type: project
originSessionId: b082ddb2-530b-45e9-a454-5dfa856fecf3
---
## What landed
Three perf changes on top of the prior Tier-1–3 work:
1. **MMIO fast-reject** — `xenia-memory/src/heap.rs` `find_mmio` now does a
single `(addr & mmio_aperture_mask) != mmio_aperture_value` compare
before falling through to the linear `iter().find` over registered
regions. Aperture pair recomputed in `add_mmio_region` via a
`fold_aperture` helper (greatest common bit-mask agreement). Fast
path is a *necessary* condition only — `contains()` still runs for
matching candidates, so MMIO semantics are unchanged.
2. **Basic-block cache** — new `xenia-cpu/src/block_cache.rs`. 64 K
direct-mapped slots keyed by `(start_pc >> 2) & 0xFFFF`, each holding
a `DecodedBlock { start_pc, end_pc, page_version, instrs }`. Block
walk stops on `PpcOpcode::terminates_block()` (branch / sc / trap /
Invalid), at `MAX_BLOCK_INSTRS = 32`, or at a 4 KiB guest-page
boundary (so single-`page_version` invalidation suffices). New
`xenia-cpu::interpreter::step_block` dispatches each instruction in
the block via the existing match-based `execute`.
3. **Hot-loop wiring + GPU pacer** —
`xenia-app/src/main.rs::run_execution` now branches on
`debugger.wants_hooks() || db_writer.is_some() ||
force_per_instr` — only the per-instruction path runs when any of
those is true. A new env var `XENIA_FORCE_PER_INSTR=1` forces the
slow path for A/B testing. Post-round GPU dispatch was changed from
"1 `execute_one` per round" to
`gpu_runs = max(1, min(64, executed_this_round / HW_THREAD_COUNT))`
so block mode (which executes ~6× more instructions per outer
round) doesn't starve the GPU.
## Why u32-narrowing and threaded-code dispatch were skipped
- **u32-narrowing**: cmpi/cmpli/cmp/rlwinm arms already cast to u32/i32
in their bodies. The remaining "obvious" target — addi/addis — runs
natively at u64 because Xenon GPRs are 64-bit. No measurable win
available without rewriting the ISA semantics.
- **Threaded-code dispatch**: extracting ~200 match arms into per-opcode
free functions for an uncertain LLVM-jump-table-vs-fn-ptr win was a
poor risk/reward. The basic-block cache benefit doesn't depend on
threaded dispatch (each instruction inside a block still goes through
the existing match), so this was the right phase to skip.
Both decisions match the plan's bench-gated rule: "Phase 4 must not be
merged on principle alone — it merges only if numbers go up."
## Numbers
Baseline (pre-perf-track) → final (`xenia-rs check sylpheed.iso -n 2_000_000`):
| metric | baseline | final | delta |
|------------------------|-----------|--------|--------|
| wall-time | 318 ms | 136 ms | 2.3× |
| `tight_alu_loop` bench | 96.9 MIPS | 114.8 | +18.5% |
| `loadstore_loop` bench | 78.3 MIPS | 91.8 | +17.2% |
| `mmio_storm` bench | 59.7 MIPS | 67.8 | +13.6% |
| workspace tests | 352 | 370 | +18 |
Bench is `cargo bench -p xenia-cpu` against the new
`crates/xenia-cpu/benches/interpreter.rs` harness. No criterion dep —
custom `harness = false` `main()`.
## Verification
- **Golden digest at -n 2M** (`crates/xenia-app/tests/golden/sylpheed_n2m.json`):
byte-identical between block and per-instruction modes.
- **VdSwap fidelity**: frame=1 fires before -n 18M; frame=2 fires
between -n 18M–22M. Prior memory said "~28 M cycles" but that
predates the GPU pacer; the actual figure with current scheduling
shifts by mode (block mode is faster wall-time but identical
instruction-count behavior up to the point of first thread
divergence).
- **Deadlock counters**: 0 halts / 0 recoveries on every Sylpheed run.
- **All 370 workspace tests pass**, including new tests:
- `xenia-memory::heap`: 5 (mmio_fast_path_*, fold_aperture_*).
- `xenia-cpu::opcode`: 5 (terminates_block_*).
- `xenia-cpu::block_cache`: 6 (build, page boundary, max-len, invalid
terminator, invalidation, hit-returns-cached).
- `xenia-cpu::interpreter`: 2 parity tests
(block_dispatch_matches_per_instruction_alu_loop +
loadstore_loop) — bit-identical CPU state between paths on a
single-thread workload.
## Important caveat: thread-interleaving divergence at large -n
At -n 30M+, the `--expect` digest **differs** between block and
per-instruction modes:
- imports diverge by ~10% (block lower)
- packets diverge by ~3.7× (block lower)
This is **fundamental to any block-batching dispatcher** in a
multi-threaded scheduler. Per-instruction mode round-robins
instructions across HW threads (HW0 ← 1 instr, HW1 ← 1 instr, …);
block mode lets HW0 burst up to MAX_BLOCK_INSTRS before yielding.
Different valid interleavings of the same multi-threaded program
reach different relative-progress states at any given total
instruction count. Both produce correct Sylpheed boots — VdSwap=1
and =2 fire, no deadlocks. Bit-identical comparison between modes
is only meaningful at -n 2M (before workers spawn) and that
remains the regression rail.
## Files touched in 2026-04-25 perf-track session
- `crates/xenia-cpu/Cargo.toml` — `[[bench]] name = "interpreter" harness = false`.
- `crates/xenia-cpu/benches/interpreter.rs` — new (3 benches).
- `crates/xenia-cpu/src/lib.rs` — `pub mod block_cache;`.
- `crates/xenia-cpu/src/block_cache.rs` — new file.
- `crates/xenia-cpu/src/interpreter.rs` — `step_block`, parity tests.
- `crates/xenia-cpu/src/opcode.rs` — `terminates_block` + tests.
- `crates/xenia-memory/src/heap.rs` — MMIO fast-reject + tests.
- `crates/xenia-app/src/main.rs` — block-cache wiring, GPU pacer,
`XENIA_FORCE_PER_INSTR` escape hatch.
- `crates/xenia-app/tests/golden/sylpheed_n2m.json` — golden digest.
## How to A/B test in future sessions
```bash
# block-cache mode (default)
./target/release/xenia-rs check <iso> -n 2_000_000 --expect crates/xenia-app/tests/golden/sylpheed_n2m.json
# force per-instruction (debugging)
XENIA_FORCE_PER_INSTR=1 ./target/release/xenia-rs check <iso> -n 2_000_000 --expect ...
# bench
cargo bench -p xenia-cpu
# or: cargo run --release --bench interpreter
```
## What's next on the perf track if needed
If Sylpheed boot is still too slow after this lands:
1. Profile with `--profile out.svg` to see where time goes now.
2. Threaded-code dispatch is still on the table — but only with a
bench showing >1.5× win on `tight_alu_loop` from a small-prototype
spike branch.
3. The `MAX_BLOCK_INSTRS = 32` cap could be tuned. Lower (16, 8)
reduces thread-interleaving divergence at the cost of dispatch wins.

196
migration/claude-memory/project_xenia_rs_ppc_audit_2026_04_29.md Normal file
View File

@@ -0,0 +1,196 @@
---
name: PPC instruction audit (2026-04-29) — addis-family bug hunt
description: Comprehensive audit of all PPC opcodes triggered by the addis 32-bit-ABI fix. Audit-only; no code changes. Findings tracker has stable PPCBUG-NNN IDs for fix-session reference.
type: project
originSessionId: a75558fe-b213-4ee1-8f1b-7b2ca696e638
---
**Audit triggered by**: the `addis` 32-bit-ABI sign-extension fix from earlier on 2026-04-29 (`project_xenia_rs_addis_signext_root_cause_2026_04_29.md`). Hypothesis: the addis bug is unlikely to be the only one of its kind among the 429 unique opcode arms in the interpreter.
**Status**: in-flight, audit-only. **No code under `xenia-rs/crates/` has been modified.** This is explicit per the plan: the deliverable is a triaged report; a follow-up session applies fixes.
**Where everything lives**:
- **Plan**: `/home/fabi/.claude/plans/we-just-found-and-stateful-sparrow.md`
- **Pre-pass red flags**: `RE Project Sylpheed/xenia-rs/audit-prepass-findings.md`
- **Per-group subagent reports**: `RE Project Sylpheed/xenia-rs/audit-out/group-NN-*.md`
- **Consolidated findings tracker (with stable PPCBUG-NNN IDs)**: `RE Project Sylpheed/xenia-rs/audit-findings.md`
**Methodology**: orchestrator (this session) does a regex pre-pass, then fans out one Sonnet subagent per opcode group (~38 groups across 8 batches), then 3 dedicated Phase-C subagents for decoder/disasm. User asked the orchestrator to checkpoint and pause between batches. Each subagent writes its report to `audit-out/group-NN-*.md`. The orchestrator appends new IDs to `audit-findings.md` after each batch.
**Phase B complete — all 8 batches done (groups 1-38, the entire interpreter)**: 224 PPCBUG IDs assigned through high-water-mark PPCBUG-519. ~50 HIGH, ~70 MEDIUM, rest LOW. The cross-cutting recommendation is **systematically truncate every GPR writeback in every integer ALU op via `as u32 as u64`**; the existing CA/CR0/OE helpers become correct without further changes once the writeback invariant is restored. Defensive secondary recommendation: `subfcx`/`subfex`/`addic`/`addicx`/`subficx` should additionally truncate their compare operands locally for resilience against future regressions.
**Batch 4 surfaced the headline find**: **PPCBUG-107 — `ReservationTable::invalidate_for_write` is defined and unit-tested in `reservation.rs:234` but never called from any store instruction in `interpreter.rs`.** Under `--parallel` mode with the table enabled, a plain `stw` by thread B to an address reserved by thread A doesn't clear thread A's reservation slot — every cross-thread atomic via lwarx/stwcx. is silently broken. Spinlocks, atomic counters, condition-variable handshakes, producer-consumer queues all fail. **This is a plausible smoking gun for the Sylpheed renderer plateau** (4 worker threads parked on never-signaled events per `project_xenia_rs_sylpheed_stage3_2026_04_29.md`). Recommended: investigate this finding ahead of all the other batch-1-2-3 fixes — it's a single small fix that could unblock the renderer.
**Other batch 2-4 highlights**:
- **PPCBUG-040** — DECODER bug: `sh64()` accessor wrong bit order for sradi (silent mis-decode).
- **PPCBUG-046** — DECODER bug: wrong MB[5] reconstruction in all 6 doubleword-rotate opcodes; `clrldi r3, r4, 32` (canonical zero-extend-to-32 idiom) becomes a no-op.
- **PPCBUG-053+054** — `bcx`/`bclrx` CTR zero-test is 64-bit; combined with PPCBUG-006 (negx) this makes `neg; mtctr; bdnz` loops run forever.
- **PPCBUG-065** — `twi 31, r0, IMM` (Xbox 360 typed-trap) drops the SIMM type code; relevant to the Sylpheed C++ throw investigation (exception-class discriminator lost).
- **PPCBUG-095..098** — pre-pass HIGH halfword-load suspects all confirmed: `lha`/`lhax`/`lhau`/`lhaux` sign-extend to 64 bits; one-line fix per opcode.
- **PPCBUG-029** — `norx` is the `not` simplified mnemonic; every `not` actively poisons GPR upper 32 bits.
**Batch 5 (stores) findings**:
- **PPCBUG-107 cascade fully mapped**: 32 store opcodes total missing `invalidate_for_write`. Single-commit mechanical sweep. Specifically: PPCBUG-130 (9 byte/halfword stores), PPCBUG-140..144 (5 word stores, including `stw`/`stwu` which are HOT — every stack push), PPCBUG-150 (5 doubleword stores), PPCBUG-160 (3 multiple/string stores; `stmw` is in every function prologue/epilogue, multi-cache-line), PPCBUG-167 (9 FP stores). Fix-shape: `if t.has_active_reservers() { t.invalidate_for_write(ea) }` before each `mem.write_*`.
- **PPCBUG-151** (NEW concurrency bug, separate from PPCBUG-107) — `stwcx.`/`stdcx.` share the same reservation slot without a width discriminator. lwarx+stdcx and ldarx+stwcx cross-pairs silently succeed when ISA says fail. Requires adding `reservation_width: u8` to `PpcContext`.
- **PPCBUG-161** — `stswx` permanent no-op (mirror of PPCBUG-123 lswx); same XER TBC fix.
- **PPCBUG-165 / 166** — `stfs*` doesn't set FPSCR exception bits during double→single narrowing, and ignores FPSCR.RN (always uses host MXCSR). Games polling FPSCR get false negatives; directed rounding (truncate/ceil/floor) wrong by up to 1 ULP. Canary shares both.
**Batch 6 (FPU) findings — better than expected**: significant FPSCR infrastructure has landed since the manual's frozen snapshots (`to_single` honors FPSCR.RN for single, `check_invalid_*` and `update_after_op` exist). PPCBUG-165/166 are specific to the store path; arithmetic ops are mostly wired up.
- **PPCBUG-184** — `fresx` computes full IEEE 1/b instead of ~12-bit hardware estimate; NR convergence sees different residuals. Canary shares.
- **PPCBUG-221** — `round_to_i64` NearestEven broken for `|v| > 2^52`; falls through to wrong rounding. Affects fctidx/fctiwx via PPCBUG-227.
- **PPCBUG-203** — fmsubx/fnmaddx/fnmsubx omit VXISI check; canonical `fnmsub`-based Newton-Raphson is hottest FPU path in graphics middleware.
- **PPCBUG-183 / 205** — fnmadd/fnmsub Rust unary `-` flips NaN sign bit; ISA says skip negation on NaN result.
- **PPCBUG-180 / 200** — XX/FR/FI inexact bits never set in any FPU op (single + double).
- **PPCBUG-201** — FPSCR.RN not honored for double arithmetic (only wired for single).
- **PPCBUG-185** — FPSCR.NI flush-to-zero not modeled (Xenon flushes subnormals).
- **PPCBUG-223** — fcmpo missing FPSCR[VXSNAN]/[VXVC] on NaN operands.
- **3 IDs retracted** by group-31 subagent after deeper analysis (PPCBUG-220/222/226). Audit methodology is self-correcting.
**Frozen-snapshot drift count: 7 opcodes** (addicx, andisx, td/tdi/tw/twi, cmp/cmpi, ldarx, stwcx). Worth a separate audit-pass after this session: `find ppc-manual -name '*.md' | xargs grep -l 'frozen snapshot'` and diff each against live code.
**Batch 7 (VMX integer add/sub + compare/min/max + logical/shift) findings**:
- **PPCBUG-275 (HIGH)** — DECODER bug: `rc_bit()` reads LSB bit 0 (correct for X/XO-form) but **VC-form vector compares put Rc at bit 10**. All 9 integer-vcmp.* opcodes have CR6 update unconditionally dead. Breaks the canonical AltiVec memchr/strncmp early-exit idiom. Fix: add `vc_rc_bit()` accessor.
- **PPCBUG-315 (HIGH)** — `vrlimi128` reads `z` field from bits 16-17 (low 2 bits of IMM) instead of bits 6-7, and `IMM` from bits 2-5 (VD128h ext + reserved) instead of 16-19. Field-extraction bug, not arithmetic.
- VMX integer add/sub (group 32) was structurally clean (only test gaps).
- VMX logical/shift (group 34) clean except vrlimi128.
**Batch 8 (VMX permute/pack + float + multiply-sum + load/store) findings — heavy**:
- **PPCBUG-360 (HIGH)** — `vperm128` reads VC permute-control from `vd128()` instead of VX128_2 VC field at integer bits 6-8. **Every `vperm128` uses the wrong control vector.** Core of every D3D vertex shader's swizzle.
- **PPCBUG-361 (HIGH)** — `vsldoi128` SH MSB read from bit 4 (reserved) instead of bit 9. **All shifts ≥8 bytes silently become 0-7.**
- **PPCBUG-362 (HIGH)** — `vpermwi128` PERMh from VD128l bits 21-23 instead of bits 6-8.
- **PPCBUG-363 (HIGH)** — `vpkd3d128` post-pack permutation **entirely absent**; the most common D3D vertex-pack pattern (`pack=1`) is always wrong. Vertex/index buffer packing for D3D is broken.
- **PPCBUG-420/421 (HIGH)** — VMX float compares (vcmpeqfp./vcmpgefp./vcmpgtfp./vcmpbfp.) hit the same rc_bit-at-bit-0 bug as PPCBUG-275; **CR6 permanently dead for ALL VMX float compare dot forms**.
- **PPCBUG-422 (HIGH)** — VMX128_R form Rc at bit 4 (different from VC form's bit 10).
- **PPCBUG-423 (HIGH)** — `vcmp*fp128.` dot forms decode as `Invalid` (decode_op6 key4 table has only non-dot keys); any game using VMX128 float compare + CR6 feedback crashes.
- **PPCBUG-424 (HIGH)** — `vmaddfp128` operand swap: computes `VA×VB+VD` but ISA says `VA×VD+VB`. Existing denorm-flush test uses aliased vA=vD which hides the bug.
- **PPCBUG-425 (HIGH)** — `vmaddcfp128` similar operand swap.
- **PPCBUG-510 (HIGH)** — `stvewx128` aligns EA to 16 bytes and writes ALL 16 bytes; ISA says word-align EA, extract one word lane, write only 4 bytes. **Every execution corrupts 12 adjacent bytes.** Non-128 stvewx is correct; 128 variant was never updated.
- **PPCBUG-511..514 (HIGH ×4)** — all 16 VMX stores missing `invalidate_for_write` (PPCBUG-107 cascade extension).
- **PPCBUG-426..437 (MED)** — VMX float arithmetic gaps mirroring scalar FPU (no NJ subnormal flush, vnmsub double-rounding, vrefp/vrsqrtefp/vexptefp/vlogefp full IEEE precision instead of ~12-bit estimate, vrfin uses half-away-from-zero, vctsxs NaN returns 0).
**DECODER/FIELD-EXTRACTION bug count: 8** (PPCBUG-040 sh64 for sradi, PPCBUG-046 mb_md for rld*, PPCBUG-275 rc_bit-VC-form, PPCBUG-315 vrlimi128 z/IMM, PPCBUG-360 vperm128 VC, PPCBUG-361 vsldoi128 SH, PPCBUG-362 vpermwi128 PERMh, PPCBUG-363 vpkd3d128 missing post-permute). All but PPCBUG-040/046 are in VX128_* forms. **Phase C decoder audit was the right call** — these field-extraction bugs were not on the pre-pass radar (which scanned interpreter.rs for arithmetic patterns only).
**Notable findings from batch 1**:
- `negx` is **active** (not latent) — `!ra` flips upper 32 bits unconditionally. Every `neg` poisons GPR.
- `subfcx` CA computation is the exact 64-bit unsigned compare that the addis bug exploited — apply defensive 32-bit truncation here regardless of upstream cleanup, because a wrong CA is unrecoverable.
- `addicx` CR0 update is a **regression** vs. the frozen snapshot in `ppc-manual/alu/addicx.md` — the manual's snapshots are useful drift detectors for other opcodes too.
- `mulli`, `mullwx` write 64-bit signed products to GPR without truncation.
- `divwx` quotient sign-extension is a same-shape-as-addis bug (Canary explicitly zero-extends here).
- Pre-pass hints REFUTED: `divwux`, `mulhwx`, `mulhwux` are clean.
**Phase C complete (decoder + disasm audit)**: 24 new IDs (PPCBUG-560..654 sparse).
**C1 (field extractors) — structural diagnosis of Phase B's 8 field-extraction bugs**:
- **PPCBUG-560 (HIGH)** — Tests-mask-bug: `rldicl()` test helper encodes sh[5:1] and sh[0] opposite to ISA. The wrong `sh64()` formula correctly inverts the wrong test encoding, so tests passed. Fix of PPCBUG-040 sh64 MUST land together with fix of test helpers.
- **PPCBUG-561..565 (MEDIUM ×5)** — 5 accessors are missing from `decoder.rs`, forcing the interpreter to inline wrong formulas: `mb_md()` (already correct in disasm.rs:1256), `vc_rc_bit()`, `vx128r_rc_bit()`, `vx128_4_imm()`/`vx128_4_z()`, `vx128_p_perm()`, `vx128_5_sh()`. Each maps directly to a Phase B finding (PPCBUG-046, 275/420, 422, 315, 362, 361). **Structural fix pattern**: promote accessors to decoder.rs as a single sweep; interpreter consumes them.
- **PPCBUG-566 (LOW)** — `xer_tbc()` missing → blocks lswx/stswx (PPCBUG-123/124/161).
- **PPCBUG-567 (LOW)** — zero scalar accessor unit tests; Phase 4 only covers VMX128 register accessors.
**C2 (opcode-lookup tables) — mostly clean**:
- **PPCBUG-600 (MEDIUM)** — formal cross-reference for PPCBUG-423: 5 VMX128 compare dot-forms missing from `decode_op6` key4 (vcmpeqfp128., vcmpgefp128., vcmpgtfp128., vcmpbfp128., vcmpequw128.).
- **PPCBUG-601 (MEDIUM)** — `decode_op6` overlapping windows; correctness depends on undocumented invariant.
- **PPCBUG-602..605 (LOW)** — undocumented dispatch quirks, test gaps.
- **All other dispatch tables match Canary entry-for-entry**.
**C3 (disassembler) — analysis-DB only impact**:
- **PPCBUG-640 (HIGH)** — `fmt_bc` emits `bdnzge`/`bdzge` for pure `bdnz`/`bdz`; `uncond` bit not checked before appending CR-condition name. Every CTR-only loop misidentified in analysis DB. Fix already exists in fmt_bclr — port the pattern.
- **PPCBUG-641 (HIGH)** — re-assessment of PPCBUG-088: every `lwsync` stored with wrong mnemonic in DB.
- **PPCBUG-643 / 644 (MEDIUM)** — SIMM and D-form displacement displayed as decimal; Canary uses hex; misaligns DB queries.
- **PPCBUG-645..654 (LOW)** — extended-mnemonic gaps, test gaps.
- **Notable**: disassembler has correct LOCAL field-extraction (mb_md, vperm128 VC, vsldoi128 SH, vpermwi128 PERM) — interpreter could just port the disassembler's helpers.
**Phase B + C — final tracker state**: ~248 PPCBUG IDs, ~55 HIGH, ~75 MEDIUM, ~110 LOW.
**Phase D complete — AUDIT FINISHED**: triaged fix-order report at `xenia-rs/audit-report-2026-04-29.md` (project root). Every one of the 253 PPCBUG IDs is referenced — verified mechanically by `grep`-comparing entry headers in `audit-findings.md` against the report. Retracted IDs (220/222/226 never reached the tracker; 482/483 marked WITHDRAWN in tracker) are explicitly listed in the report's Notes.
**Recommended fix order (8 phases) — abridged**:
- **P1 — PPCBUG-107 cascade** (cross-thread atomicity): single mechanical sweep adding `invalidate_for_write` to ~38 store sites. Likely Sylpheed renderer plateau cause.
- **P2 — Decoder/field-extraction sweep**: 6 missing decoder accessors (PPCBUG-561-565), `sh64()` fix + test helper fix (PPCBUG-040+560 must land together), `decode_op6` dot-form key entries (PPCBUG-423+600).
- **P3 — Other HIGH bugs**: stvewx128 corruption (PPCBUG-510), vmaddfp128/vmaddcfp128 operand swap (PPCBUG-424/425), bcx CTR 32-bit (PPCBUG-053+054), fmt_bc spurious suffix (PPCBUG-640), lwsync/sync (PPCBUG-641).
- **P4 — 32-bit ABI writeback truncation sweep**: ~30 IDs across active poisoning (negx/norx family), addis-shape (addi/addic/divwx etc.), latent writebacks, and CR0 width.
- **P5 — FPU correctness**: round_to_i64 near-2^52, FMA VXISI gaps, NaN sign preservation, FPSCR exception bits, subnormal flush, estimate precision.
- **P6 — Other MEDIUM**: trap pc-after-advance, sc LEV, twi typed-trap (PPCBUG-065 — relevant to Sylpheed C++ throw work), mtmsrd L=1, lswx/stswx XER TBC enabling.
- **P7 — Frozen-snapshot drift sweep** (8 opcodes).
- **P8 — Test gaps** (~50 IDs; bundle with each fix PR).
**Coupled-fix matrix**: 14 must-land-together pairs documented in the report's Coupling matrix.
## Fix session progress (2026-05-01)
**P1 — Cross-thread atomicity sweep — MERGED (ca5b90b, 2026-05-01)**
- PPCBUGs fixed: 107, 108, 130, 140-144, 150, 151, 160, 167, 511-514 + review additions (dcbz, dcbz128 guards; stswi/stswx two-line guards)
- `cargo test --workspace --release`: 449 passed, 0 failed
- Acid test `-n 4B --parallel --reservations-table`: **swaps=2, draws=0** — renderer plateau NOT unblocked by P1. Atomics were broken, but that was not the direct cause of `draws=0`.
**P2 — Decoder/field-extraction sweep — MERGED (52b05b1, 2026-05-01)**
- PPCBUGs fixed: 040, 046, 275, 276, 315, 360, 361, 362, 363, 369, 420, 421, 422, 423, 560, 561, 562, 563, 564, 565, 600 (21 IDs, 8 commits)
- Key fixes: sh64() bit order, mb_md() (clrldi no-op fixed), vc_rc_bit()/vx128r_rc_bit() Rc accessors + 13 vcmp sites, vrlimi128/vsldoi128/vpermwi128 field extraction, vperm128 vc field, vpkd3d128 post-pack permutation
- `cargo test --workspace --release`: 201+6+144+76+16+8+… passed, 0 failed (well above 506+ baseline)
- Independent code review: all 9 check items OK
- Acid test: **pending** (sylpheed.iso not available in CI; must run on user machine)
- Next: P3 — isolated HIGH bugs. Priority order: PPCBUG-510 (stvewx128 16-byte corruption), PPCBUG-424+425 (vmaddfp128/vmaddcfp128 operand swap), PPCBUG-053+054 (bcx CTR 32-bit + mtspr CTR truncation, **coupled**), PPCBUG-640 (fmt_bc spurious suffix), PPCBUG-641 (lwsync vs sync).
**P3 — Isolated HIGH bugs — MERGED (f3ebaba, 2026-05-02)**
- PPCBUGs fixed: 053+054 (coupled CTR 32-bit), 424+425 (vmaddfp128/vmaddcfp128 operand swap), 510 (stvewx128 corruption), 640+650 (bdnz/bdz suffix), 641+649 (sync/lwsync), **700 (NEW)** (6 commits)
- **PPCBUG-700 — discovered during phase end-to-end review**: VMX128 register accessors (va128/vb128/vd128/vx128r_rc_bit) all disagreed with canary's bitfield struct (xenia-canary `ppc_decode_data.h:484-663`). Audit's line-2958 "confirmed-clean" assessment was based on miscounting LSB-first packed C++ bitfields. Per canary: VA = PPC[11-15] | PPC[26]<<5 | PPC[21]<<6 (3 fields, 7 bits); VB = PPC[16-20] | PPC[30-31]<<5; VD = PPC[6-10] | PPC[28-29]<<5; VX128_R Rc = PPC[25] (NOT PPC[27] as PPCBUG-422 said). Affects 30+ VMX128 opcodes; real game code with VR>=32 was silently mis-decoded. Now correct.
- `cargo test --workspace --release`: **470 passed, 0 failed**
- Acid test: **deferred to end of all phases** (per user direction).
- Next: P4 — 32-bit ABI writeback truncation sweep. ~30 IDs across 4a-4d.
**P4 — 32-bit ABI writeback truncation sweep — MERGED (d945aea, 2026-05-02)**
- PPCBUGs fixed: ~43 IDs across 7 commits (6 batches + 1 review-fix). The big systemic sweep that restores the 32-bit ABI invariant: every GPR write zero-extends from u32, every CR0 update views the result as i32.
- Batches: 4a active poisoning NOT/SUB (006/008/018/019/028/029/030/031/033); 4a/4d coupled extsbx+extshx+CR0 (034-037); 4b immediate ALU (001-005/007); 4b mul/div + srawx coupled (009/010+011/041+042+043); 4b halfword + lwa loads (095-098/105); 4c latent + 4d CR0 catch-all (012-017/020/023-026/032/044).
- **Review-fix (49103bb)**: independent reviewer caught a blocking issue — subfx/subfcx OE handlers still used legacy `sum_overflow_64` (the helper assumes a 64-bit result; for 32-bit results with bit 31 set it spuriously flagged OV=1 on every legitimate i32::MIN). Now uses inline `true_diff != (result32 as i32) as i128`. Plus discriminating regression tests for both subfo and subfco. Reviewer also caught `mulli_overflow_wraps_to_32` rubber-stamping (test passed on both pre/post fix); rewritten with polluted upper bits.
- `cargo test --workspace --release`: **494 passed, 0 failed**
- Acid test: **deferred to end of all phases** per user direction.
**P5 — FPU correctness — MERGED (d39d0ba, 2026-05-02)**
- PPCBUGs fixed: ~22 IDs across 7 commits (6 batches + review-fix nit).
- Batches: 5a round_to_i64 + vrfin round-to-even (221+227, 432); 5b FMA VXISI + NaN sign (181/182/183/202/203/205) — added new `check_invalid_fma_add` helper to fpscr.rs; 5c FPU XX-on-inexact (223/224/225/229/230); 5d VSCR.NJ subnormal flush (435/436/437); 5e fresx canary parity (184); 5f single-FMA vnmsubfp + vctsxs NaN sat (426/427/433).
- **Three deferred** (audit-findings status remains open): PPCBUG-201 (FPSCR.RN for double arithmetic — MXCSR set/restore wrappers), PPCBUG-185 (FPSCR.NI flush for scalar FPU — NI bit constant + post-op flush wrapper), PPCBUG-180/200 (XX/FR/FI in update_after_op — pre/post round comparison). Each requires substantial helper rework; planned as focused sub-batches.
- Review verdict: "MERGE-READY" — no blocking issues. One reviewer nit applied immediately (vrfin → stdlib `round_ties_even()`).
- `cargo test --workspace --release`: **498 passed, 0 failed**
**P6 — Other MEDIUM correctness — MERGED (112202c, 2026-05-02)**
- PPCBUGs fixed: 13 IDs across 5 commits (4 batches + review nit).
- Batches: trap PC + sc LEV logging + typed-trap logging (063/064/065); XER TBC infrastructure enabling lswx/stswx + lswi/stswi nb fix + lmw RA-skip (123/124/125/126/161/162/566); mcrfs VX recompute + mtmsrd L=1 + mfvscr zero (068/078/080); mulld_ov verification + auto-resolved markers for 021/022/027/039.
- **Structural enum extensions deferred** (not yet needed by any consumer): `StepResult::HypervisorCall` (PPCBUG-064 sc 2 routing), `StepResult::Trap { type_code: u16 }` (PPCBUG-065 typed-trap routing — relevant if SEH dispatch added).
- **Cosmetic/test-coverage deferrals**: 642 (fmt_bcctr ISA-undefined), 643/644 (SIMM/D-form hex), 367/368 (vupkhpx/vpkpx channels), 487/495 (vsum naming), 515/516 (lvebx/lvsr docs), 601 (decode_op6 invariant doc).
- Review verdict: all 4 commits LGTM, one cosmetic nit applied (mcrfs uses fpscr::VX_ALL constant). No blocking issues.
- `cargo test --workspace --release`: **498 passed, 0 failed**
**P7 — Frozen-snapshot drift — MERGED (a7155f4, 2026-05-02, manual regen — no xenia-rs code change)**
- PPCBUGs cleared: 3 IDs (066, 117, 145) — stale `ppc-manual/<cat>/<op>.md` snapshots.
- Methodology: ran `python3 ppc-manual/generator/generate_manual.py`. Existing idempotent generator scrapes xenia-rs + xenia-canary source for each opcode and emits 350 family pages + 598-key index.json. Verified post-regen: old "For now, just trace and continue" stubs gone; modern constructs (trap::evaluate, current reservation_line model) appear correctly.
- The `ppc-manual/` directory lives in `/home/fabi/RE Project Sylpheed/ppc-manual/` and is NOT versioned in xenia-rs/.git. Commit a7155f4 in xenia-rs is bookkeeping only (audit-findings + report).
**P8 — Test gap closure — MERGED (4029041, 2026-05-02)**
- 38 IDs closed across branch/CR/SPR/sync, loads, stores, FPU, VMX (integer/float/permute/load-store).
- Batches: 4 batches + review-fix rename = 5 commits. 53 net new tests.
- Review verdict: LGTM, no blocking issues, no rubber-stamps. Every hand-encoded raw was mechanically cross-checked against canary's INSTRUCTION table.
- Load-bearing wins: `lswx_uses_xer_tbc_for_byte_count` and `stswx_uses_xer_tbc_for_byte_count` directly exercise the P6 XER-TBC infrastructure (these opcodes were permanent no-ops pre-P6). VX-form encoding nit caught + corrected mid-development (XO is at bit 0, not bit 1).
- ~12 LOW test-gap IDs remain Status: open (045, 047, 088, 117 already-applied, 145 already-applied, 279, 317, 322, 324, 325, 371-378, 491-494, 518, 519, 567) — non-blocking, can be closed incrementally.
- `cargo test --workspace --release`: **551 passed, 0 failed** (up 53 from 498 at P7 merge).
- Acid test: **deferred to end of all phases** per user direction.
**ALL EIGHT PHASES COMPLETE.** Total ~161 PPCBUGs applied across 8 phases.
**Post-P8 end-to-end review + acid test (2026-05-02)**:
- Reviewer caught one BLOCKING-LIKELY issue: my P4 batch 5 PPCBUG-105 fix changed `lwa`/`lwax`/`lwaux` from sign-extend to zero-extend, deviating from PowerISA. Hotfix at HEAD f1166d0 restored ISA-spec sign-extension. Rationale: ISA-deviation in a 64-bit-mode opcode could break any kernel-mode code; the audit's "32-bit-ABI hazard" concern was speculative.
- Cosmetic fix at HEAD 09c6c92: collapsed `fpscr.rs:289` duplicate-branch typo.
- Acid test `-n 4B --parallel --reservations-table`: **swaps=1, draws=0** (NOT swaps=2 like P1; possibly due to scheduler chatter slowing things or a minor regression in some cumulative fix). No panics, no errors, no RtlRaiseException. **Renderer plateau NOT unblocked** by the cumulative PPC correctness fixes.
- **Implication**: the Sylpheed renderer `draws=0` plateau has a non-PPC-correctness root cause. The audit caught real bugs (well-grounded against canary), but they're not the renderer-blocker. Next investigation tracks: graphics-pipeline (EDRAM resolve, RT readback), kernel HLE (event signaling, timers), or the unresolved BST-validation paradox (per `project_xenia_rs_sylpheed_event_chain_2026_04_29.md`).
- **551 tests passing**, **0 failures** at master HEAD (post-hotfixes).
**Where everything lives**:
- **Fix plan**: `/home/fabi/.claude/plans/i-want-to-apply-delightful-lovelace.md`
- **Pre-pass triage**: `xenia-rs/audit-prepass-findings.md`
- **Per-group reports**: `xenia-rs/audit-out/group-NN-*.md` and `xenia-rs/audit-out/phase-cN-*.md`
- **Detailed findings tracker** (per-PPCBUG entries): `xenia-rs/audit-findings.md`
- **Triaged fix-order plan**: `xenia-rs/audit-report-2026-04-29.md` ← **start here for the fix session**
**What the fix session should do next**:
1. Read `xenia-rs/audit-findings.md` end-to-end. Each PPCBUG-NNN has location, fix snippet, and notes.
2. Apply fixes in dependency order. PPCBUG-010 + PPCBUG-011 (divwx writeback + CR0) **must** land in the same commit. PPCBUG-012..-019 (latent writebacks) can land in any order but should land before PPCBUG-020 (CR0 catch-all sweep).
3. Add the proposed unit tests — particularly for `subfcx`, `addic`, `addicx`, `mulli`, `subficx`, `negx` which currently have zero coverage.
4. After each fix, run `cargo test --workspace --release` and `xenia-rs check sylpheed.iso -n 100M` to detect regressions.
5. The acid test is whether the Sylpheed renderer plateau (`swaps=2, draws=0`) breaks open after applying the high-priority fixes. The hypothesis is that one or more of these latent bugs is the next-domino-after-addis.

120
migration/claude-memory/project_xenia_rs_producer_stack_trace_2026_05_03.md Normal file
View File

@@ -0,0 +1,120 @@
---
name: producer stack-trace diagnostic + parked-waiter creator IDs (KRNBUG-AUDIT-002)
description: 2026-05-03 — diagnostic-only multi-frame guest stack capture at NtCreateEvent; identified subsystems for handles 0x1004 / 0x100c / 0x15e0; corrected project_memory typo (0x15e4 → 0x15e0); 0x42450b5c is a guest-pointer wait, not a handle.
type: project
originSessionId: fc916bd6-940d-4d2f-9875-03af1d5a8493
---
**🔍 KRNBUG-AUDIT-002 (2026-05-03)** — diagnostic landed, producer not yet
fixed. Tests 576 → 581. Lockstep `sylpheed_n50m` golden BIT-IDENTICAL.
Master untouched (no commit yet — work sits in working tree).
**Why:** the previous session's KRNBUG-AUDIT-001 told us the producer is
missing for the parked-waiter handles, but every handle's `created lr`
points at the same `silph::Event` ctor wrapper (sub_824A9F18, 83
callers) — useless for subsystem ID. Needed multi-frame stack at
allocation time.
**How to apply:** when chasing a producer for a parked Event/Semaphore
handle, add it to `--trace-handles-focus=…` and the next run dumps a
6-frame back-chain under `created stack`. Walker is in
`crates/xenia-kernel/src/state.rs::walk_guest_back_chain` (reads
`[r1]`/`[prev_sp - 8]`; gated on focus set; one `HashSet::contains` on
unfocused hot path; verified read-only — no determinism impact).
------------------------------------------------------------------------
**Confirmed creator chains (every captured frame cross-checked against
sylpheed.db `instructions` — saved-LR matches a `bl` site exactly):**
| Handle | Tid | Creator chain | Pool size |
|---|---|---|---|
| 0x1004 | 10 | static-ctor 0x8280F810 → sub_8217C850 → sub_821783D8 → sub_824A9F18 | **8-instance pool** (static ctor calls bridge sub_8217C850 8 times) |
| 0x100c | 2 | entry_point + 0x198 → sub_8216EA68 (= main) → sub_82181C20 → sub_821800D8 → sub_82181750 → sub_824A9F18 | singleton (called inside main()) |
| 0x15e0 | 16 | sub_82172BA0 → sub_821707C0 → sub_8216F618 → sub_821701C8 → sub_824A9F18 | singleton (different cluster from 0x100c) |
All 3 ctors share **identical 4-callee shape**:
`RtlInitializeCriticalSectionAndSpinCount` + silph::Event ctor + 1-2
silph internals. All 3 worker entries call `sub_824AA658(r3=-2, r4=5)`
first thing (silph::Thread::SetProcessor(CURRENT, 5)), then
spinlock + `RtlEnterCriticalSection` + check queue. **Canonical
work-queue worker pattern** — producer should `NtSetEvent(handle)`
under the CS but no such call ever fires in 500M instructions.
------------------------------------------------------------------------
**Corrections to prior session memory:**
- The 4-handle list `0x1004, 0x100c, 0x15e4, 0x42450b5c` had
`0x15e4` as a transcription error — actual handle is `0x15e0`.
Confirmed via `--halt-on-deadlock` thread diagnostic:
`tid=16 hw=4 idx=1 state=Blocked(WaitAny { handles: [5600] })`
(5600 = 0x15e0).
- `0x42450b5c` is **NOT a kernel handle** — `>= 0x40000000` is the
guest user heap range (handle table starts at 0x1000+4n). Tid=6
is parking on a guest pointer (embedded `KEVENT`?) reached via a
non-`do_wait_single` wait path: audit shows
`<UNCREATED> <AUDIT_BLIND>` (waits=0 despite waiter_count=1).
Treat as separate bug class — needs hooks on the
`KeWaitForSingleObject(*PDISPATCHER_HEADER)` path.
------------------------------------------------------------------------
**Wider parked-waiter set (-n 500M, halt-on-deadlock):**
| Handle | Tid | Notes |
|---|---|---|
| 0x1004 | 10 | Event/Manual, 8-pool, sole waiter |
| 0x100c | 2 | Event/Manual, singleton |
| 0x15e0 | 16 | Event/Manual, singleton |
| 0x12f4 | 13, 14 | Semaphore, 2 waiters share it |
| 0x15f8 | 18 | Event/Auto, do_wait_multiple |
| 0x1038 | 4 | Event/Auto, in WaitAny[0x1038, 0x103c] |
| 0x10b0 | 5 | Event/Auto, in WaitAny[0x10b0, 0x10b4] |
| 0x42450b5c | 6 | guest-pointer wait (separate bug) |
------------------------------------------------------------------------
**Next session — surgical producer hunt (do not pivot to fix yet):**
1. **Per-handle vtable readout**: at the worker's wait point, the
`this` pointer is in `r3`/`r28` at function entry. Read
`*this[0]` (vftable addr), then vftable[-1] → MSVC RTTI
`TypeDescriptor` → class name string. Resolves the exact
`SilpheedSCS::*` class. RTTI candidates already located in PE:
`WorkHudThread2`, `WorkHudThreadTaskCaller`, `CTaskUpdater`,
`CRenderCommandQueue`, `CCollisionManager`, etc.
2. **Find producer**: once class is named, grep PE strings +
sylpheed.db for `Push*`/`Submit*`/`Enqueue*` methods on the
class. Their signal call (silph::Event::Set wrapper, not
sub_824A9F18 itself) → check whether it ever runs.
3. **Two failure modes:**
- **(A) KeSetEvent on embedded KEVENT bypasses handle waiter list**
— same family as 0x42450b5c. Smoking gun: metric
`kernel.calls{name=KeSetEvent}` is non-zero but audit shows
zero signals for the handle.
- **(B) Producer never reached** — UI/timer/vsync gate. Smoking
gun: `kernel.calls{KeSetEvent}` zero for the handle.
4. **0x42450b5c**: instrument the non-`do_wait_single` wait path
(PC=0x824cd4f4, function entry NOT in analyser's `functions`
table — likely a `KeWaitForSingleObject(*PDISPATCHER_HEADER)`
wrapper). Once audited, repeat steps 1-3.
------------------------------------------------------------------------
**Build state:** working tree only — no commit. Files touched:
- `crates/xenia-kernel/src/audit.rs` (+`record_create_with_stack`,
+`created_stack` field, +2 tests)
- `crates/xenia-kernel/src/state.rs` (+`audit_create_with_ctx`,
+`walk_guest_back_chain`, +3 tests)
- `crates/xenia-kernel/src/exports.rs` (`nt_create_event`,
`nt_create_semaphore`, `nt_create_timer` switched to new helper)
- `crates/xenia-kernel/src/xam.rs` (`xam_task_schedule` switched;
removed dead `let lr = ctx.lr as u32`)
- `crates/xenia-app/src/main.rs` (focus dump prints
`created stack (N frames)` block)
- `audit-findings.md` (KRNBUG-AUDIT-002 entry + producer-trace
finding appended)
Master HEAD per prior memory: `9d45efe`. Tests on this branch: 581
(was 576). Goldens: `sylpheed_n50m.json` re-confirmed BIT-IDENTICAL
under `--stable-digest`.

56
migration/claude-memory/project_xenia_rs_scheduler.md Normal file
View File

@@ -0,0 +1,56 @@
---
name: xenia-rs scheduler architecture (post-Axis-1-to-5 refactor, 2026-04-23)
description: Canonical scheduler model — 6 HW slots × per-slot priority runqueues, single host thread, GuestThread as first-class, ThreadRef identity, bind-and-migrate affinity. Supersedes the old HwThread[32] one-thread-per-slot model.
type: project
originSessionId: a178fdd6-2965-4652-903a-f684cf80835d
---
## Model in one paragraph
Single host thread runs the interpreter (`GuestMemory` pinned). Scheduler has **6 `HwSlot`s** matching Xenon hardware. Each slot holds `runqueue: Vec<GuestThread>` + `running_idx: Option<usize>`. A `GuestThread` owns its own `PpcContext` inline — the live register file is always the one on whichever thread the slot has pinned as running, so context switch is just a `running_idx` flip (no memcpy). Unlimited guest threads per slot.
## Identity
`ThreadRef { hw_id: u8, idx: u16 }` — 4-byte positional identity used across the boundary. Waiter lists in `KernelObject::{Event,Semaphore,Mutex,Thread}`, `state.cs_waiters`, `interrupts.injected_ref`, and `scheduler.timed_waits` all store `ThreadRef` (not raw hw_id). After `swap_remove` (Axis 4 migration), refs are fixed up via `MigrationFixup::apply`.
## Compat accessors (how ~30 call-sites survived the data-model refactor)
`scheduler.ctx(hw_id) / ctx_mut(hw_id) / ctx_mut_ref(r) / state(hw_id) / tid(hw_id) / thread_handle(hw_id) / suspend_count_mut(hw_id) / current_hw_id()` — each resolves through `slots[hw_id].running_idx`. Safe sentinel (`idle_ctx`) returned when running_idx is None. This let the refactor avoid rewriting every `hw_threads[i].ctx` site in [main.rs](xenia-rs/crates/xenia-app/src/main.rs) and [exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs).
## Scheduling
- **`HwSlot::pick_runnable`** — highest-priority Ready/ServicingIrq thread; tiebreak lowest idx.
- **`Scheduler::round_schedule`** — emits slot ids in rotating order starting from `rotation_cursor`, filtered by `non_empty_runnable: u8` bitset. Empty-slot fast path. `OrderMode::Seeded` layers Fisher-Yates on top of the filtered list.
- **`Scheduler::begin_slot_visit(hw_id)`** — called by main.rs at top of each slot iteration; picks runnable, sets `running_idx`, writes `self.current: Option<ThreadRef>`.
- **`Scheduler::decrement_quantum()`** — Axis 3 per-instruction tick; on hit-zero, reloads to `QUANTUM_DEFAULT = 50_000` and rotates within same-priority tier (observed next round, not mid-instruction).
## Affinity + priority (Axis 4/5 wire-up)
- **`KeSetAffinityThread(handle, mask) -> old_mask`** does real migration: `set_affinity_ref` finds the thread, updates mask, if current slot no longer allowed → `swap_remove` from source slot, push onto least-depth allowed slot, rewrite `PCR+0x2C`, return `MigrationFixup`. `KernelState::set_affinity` walks every waiter list and applies the fixup.
- **Self-migration handling**: if the migrating thread is `scheduler.current`, the ref is updated in place. `call_export`'s post-call ctx restore re-reads `current` (not the stashed entry ref) so ctx lands on the new slot. `main.rs`'s post-export `pc = lr` advance uses `post_ref = scheduler.current` for the same reason.
- **`KeSetBasePriorityThread` / `KeQueryBasePriorityThread`** store/read `GuestThread.priority: i32`. NT-style [-15..+15], default 0. Drives `pick_runnable`.
- **`KeSetIdealProcessor` / `KeQueryIdealProcessor` / `NtSetInformationThread`** (classes 2/3/13) wired; ideal is a spawn-placement hint (not migrate-on-change).
## Lifecycle details
- `exit_current` flips state to `Exited(code)` but does NOT `Vec::remove` (would invalidate peer ThreadRefs). Pruning happens at `spawn` time via `prune_exited_if_needed` when a slot reaches `PRUNE_DEPTH_THRESHOLD = 4`.
- `install_initial_thread` on `Scheduler` lives next to `spawn`; both write `PCR+0x2C = hw_id` via the `PcrWriter` trait (impl `GuestMemoryPcr` in [state.rs](xenia-rs/crates/xenia-kernel/src/state.rs)).
- `KernelObject::Thread.waiters: Vec<ThreadRef>` (not `Vec<u8>`) — necessary for correctness under per-slot runqueues.
## Known caveat (2026-04-23)
Axis 4's real migration distributes Sylpheed's workers across slots differently than the old 32-slot one-per-slot model. The resulting wait/signal chain trips a single `scheduler.deadlock_recoveries` event during boot; default force-wake recovery resolves it and the game progresses to **VdSwap=2** (up from pre-Axis-4's 1). Under `--halt-on-deadlock` this trips `scheduler.deadlock_halts = 1` at ~7.5M cycles. The issue is a latent HLE sync-primitive gap exposed by correct migration, not an Axis 4 defect. Root cause: one of tid=1/3/4/7's blocking events isn't being signaled by its expected source after thread layout changes. Track down by instrumenting the specific handle values (0x10FC, 0x1014, 0x1104, 0x10DC/0x10F0) in a future session.
## Files
- [xenia-cpu/src/scheduler.rs](xenia-rs/crates/xenia-cpu/src/scheduler.rs) — workhorse (~35 tests covering all 5 axes)
- [xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs) — `KernelState::set_affinity` orchestrator, `call_export` ctx swap via `ThreadRef`
- [xenia-kernel/src/exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs) — `ke_set_affinity_thread` (0x97), `ke_set_base_priority_thread` (0x99), `ke_query_base_priority_thread` (0x81), `ke_set_ideal_processor` (0x98), `ke_query_ideal_processor` (0x82), `nt_set_information_thread` (0xFB)
- [xenia-kernel/src/objects.rs](xenia-rs/crates/xenia-kernel/src/objects.rs) — waiter lists as `Vec<ThreadRef>`
- [xenia-kernel/src/interrupts.rs](xenia-rs/crates/xenia-kernel/src/interrupts.rs) — `injected_ref: Option<ThreadRef>` (not `injected_hw: u8`)
## Metrics added
- `scheduler.spawn.ok` — successful spawns
- `scheduler.spawn.rejected` — spawn failures (should stay 0)
- `scheduler.deadlock_recoveries` — force-wake events (non-zero post-Axis-4; see caveat)
- `scheduler.deadlock_halts` — halts under `--halt-on-deadlock`

158
migration/claude-memory/project_xenia_rs_sylpheed_event_chain_2026_04_29.md Normal file
View File

@@ -0,0 +1,158 @@
---
name: Sylpheed event 0x1004 producer trace (2026-04-29)
description: Identified the C++ singleton structure for tid=10 worker, found the destructor is the ONLY signaler of event 0x1004; the runtime "wake worker for work" path is unidentified.
type: project
originSessionId: c44cbfc2-438f-45c9-996c-06eddf9dcb93
---
## What was traced
Goal: identify what should signal `Event/Manual` handle 0x1004 (waited on by tid=10, sub_82178950) so that the renderer worker can wake and progress.
Used `--trace-handles` audit at -n 500M and DuckDB analysis DB. Key chain:
### The singleton at 0x828F3EC0
- 4-byte struct, 180 bytes long, zero-initialized by [`sub_822C1D00`](xenia-rs/sylpheed.db).
- Initialized by [`sub_821783D8`](xenia-rs/sylpheed.db) which:
- Registers in BST via `sub_82454498` + `sub_82454580` (the same BST validator chain we hit the throw on)
- Calls Sylpheed's CreateEvent wrapper [`sub_824A9F18`](xenia-rs/sylpheed.db) at 0x821784F4 → returns event handle 0x1004
- Stores handle at `singleton[+120]` (so `mem[0x828F3F38] = 0x1004`)
- Singleton accessor (init-on-first-use): [`sub_8217C850`](xenia-rs/sylpheed.db) — checks init flags at 0x828F4888 / 0x828F4898, calls initializer, registers DESTRUCTOR via atexit (`sub_825ED268`).
### The thread-spawning chain
- [`sub_82178E50`](xenia-rs/sylpheed.db) is the worker's "start" function. Called from [`sub_821737F0`](xenia-rs/sylpheed.db).
- It enters CS, sets `singleton[+132] |= 1` (running flag), calls `bl 0x8216DE98` (queues work via copy-into-buffer, NO event signal here), calls `sub_82178F60` (which itself calls `sub_82175F10` — yes, the same `sub_82175F10` from the throw investigation), and if successful calls `sub_82172370` (ExCreateThread wrapper) with entry=`sub_82178950` and start_ctx=`0x828F3EC0`.
- Stores returned thread handle at `singleton[+116]`.
### The worker's wait pattern
`sub_82178950` (tid=10's entry):
1. Init helpers (allocate workspace via `sub_82455730(0x7FFFFFFF)`)
2. **`bl sub_824AA330`** with `r3 = singleton[+120] = 0x1004`, `r4 = -1` → wait FOREVER on event 0x1004
3. After waking, check `singleton[+132] & 0x10000` (bit 16): if set → exit; else → jump to work loop at 0x82178DB8
### The only known signaler — the destructor
Function at `0x82178600` (no direct callers found in xrefs):
- Reads `singleton[+132] & 0x1` (running flag); if not set, skip.
- Else: set `singleton[+132] |= 0x10000` (bit 16 = "exit requested"), `bl sub_824AA2F0` (SetEvent wrapper) on `singleton[+120] = 0x1004`, then `bl sub_824AA330` to wait_single on `singleton[+116]` (join the thread), then enter CS and cleanup.
This is registered as a destructor via atexit (`sub_825ED268`) inside `sub_8217C850` at instruction 0x8217C8B0 with arg=trampoline 0x8284C9E0 (which loads `0x828F3EC0` and tail-calls the destructor function). atexit destructors only fire at program exit — never during normal runtime.
## The mystery
**During normal runtime, NOTHING signals event 0x1004 to wake tid=10 for actual work.** The destructor only runs at program exit. Audit confirms: 0 signals on event 0x1004 at -n 500M. tid=10 sits in `bl sub_824AA330` forever, holding up the renderer chain.
This is true for the same pattern with events 0x100c, 0x15e4, 0x42450b5c (all Manual reset, all `<NO_SIGNALS_DESPITE_WAITS>`).
## What's NOT the answer
- It's NOT a missing direct call: 89 callers of the SetEvent wrapper sub_824AA2F0 were enumerated; none signal these specific events.
- It's NOT a vtable dispatch we missed: searches for stores of 0x82178600/0x82178608 to static data find nothing.
- It's NOT in `sub_8216DE98` (the queue-work fn): it's a `memcpy`-into-ringbuffer-style copy, no SetEvent.
- It's NOT in `sub_82178F60` (the spawn-prep fn): it does string compares with config keys ("PATH"/"SETTINGS") and ends up calling `sub_82175F10` (the throw site) — but no SetEvent on 0x1004.
## Hypothesis for next session
The signaling must come via one of these mechanisms (not yet checked):
1. **Indirect dispatch via a function pointer stored at runtime**. Sylpheed's BST registry (the same one that caused the throw) might store function pointers as part of "registered objects". When some event happens (e.g., a frame deadline), the registry's registered callbacks fire — and one of those callbacks signals the event. The fact that `sub_821783D8` registers `singleton[+56]` in the BST is highly suspicious.
2. **A timer-driven dispatch**. The 32-times-waited timer 0x15c0 in the audit is interesting: it's `Timer/Auto` with deadline driven by NtSetTimerEx. The timer fires periodically. Some periodic callback might signal the worker events.
3. **Polling vs event-driven mismatch**. Sylpheed might EXPECT the worker to wake periodically (e.g., from a timer or vsync interrupt) rather than from a discrete event. We may be holding the wait too tightly when the game expects spurious wakeups.
## Concrete next steps for a future session
### Step 1 (quick) — DONE: the BST callback walker doesn't exist as expected
Searched for it: in BST module 0x82454000..0x82455000 (20 functions, 4 KiB), only TWO indirect calls (`bcctrl`) exist — both are byte-level string transforms (`sub_82454278` iterates over a buffer of bytes, `sub_82454170` is a single-shot vtable call), NOT a "for each registered object call method" walker. Functions that call BOTH `sub_82454498` (BST getter) AND `sub_824AA2F0` (SetEvent wrapper) are only 4: `sub_821783D8` (DB-misattributed; actually the destructor at 0x82178600), `sub_8228D760` (lazy event create+signal for one specific object, not a walker), `sub_822AE1F0` (config processing), `sub_8280C2C0` (renderer-wide static initializer). NONE of them iterate the BST and dispatch callbacks. **The BST is purely a validity registry, not a callback registry.**
### Step 2 — RUNTIME APPROACH (recommended next): Canary boot trace diff
With static analysis exhausted, this is the most likely productive direction. Run `xenia-canary` against the same ISO with verbose threading + event logging (`--log-debug=1` flag in canary). Capture:
- The sequence of NtCreateEvent / NtSetEvent / NtWaitForSingleObjectEx calls
- Which threads (by tid mapping) signal which handles
- The order of guest-LR addresses at each NtSetEvent call
Diff against our audit. The first signal call on Canary that we never make is the missing piece. If Canary never signals 0x1004 either, then it must not block on it the same way — meaning some upstream HLE returns differently and the worker takes a different code path that doesn't reach the wait at sub_82178950+0x821789C4.
### Step 3 — Targeted instrumentation: dump per-handle histogram from our run
Modify `nt_set_event` and `nt_wait_*` to log `(handle, lr, tid)` to a structured trace file. Add same to `wake_eligible_waiters`. Run for `-n 5_000_000_000` (~3 min). Cross-correlate per-handle. This gives a per-handle time series that the audit's bounded ring can't.
### Step 4 — Hypothesis: the worker at 0x82178DB8 *should* be reachable WITHOUT signal
The post-wait code at sub_82178950+0x821789C8 reads `singleton[+132] & 0x10000`; if NOT set, jumps to 0x82178DB8 to do work. The wait at 0x821789C4 is INFINITE. So the worker requires SOME wake. But what if the "first wake" is supposed to come from the spawner thread completing some work BEFORE spawning the worker, then immediately signaling? Trace `sub_82178E50`'s exact return path with instrumentation: does it `bl 0x824AA2F0` on `singleton[+120]` after spawning that we missed? (The destructor signals; check carefully whether the START path in `sub_82178E50`'s "already_running" branch (0x82178E80..0x82178EB0) signals via `bl sub_8216DE98` — note bl 0x8216DE98 *queues* but doesn't signal. Look one level up at the caller `sub_821737F0`.)
## Files unchanged this session
No code changes. Investigation only. Throw-fix from [project_xenia_rs_sylpheed_throw_fix_2026_04_29.md](project_xenia_rs_sylpheed_throw_fix_2026_04_29.md) is the only modification active.
## Open question for the user
Step 1 was attempted in this session and ruled out: the BST is not a callback registry. The most promising next direction is Step 2 (Canary diff) — pure analytical work has exhausted what's tractable; we need a ground-truth comparison.
## Final session findings (2026-04-29 update)
Traced one level up: the caller of `sub_82178E50` (spawner) is `silph::Silph::Impl::OnInit` at 0x82173990 (no DB function entry — discovered via xref + `addi r5, r11, 6076` string load matching the 'silph::Silph::Impl::OnInit' message). The OnInit body runs:
1. `bl 0x8217C850` — singleton accessor (returns thread_obj_ptr)
2. `bl sub_82178E50` — spawn tid=10
3. Various config processing (string lookups, no event signals)
4. `bl 0x821835E0` — string-table lookup (29 entries at 0x820A_0000+5680), returns index or 30 if not found. **Returns 28 means specific string match → success path; else returns 30 → exit with failure**.
5. If success: printf "RenderDevice initialized. spend %d ms.\r\n" + more cleanup
**No event 0x1004 signal anywhere in OnInit's execution after spawning tid=10.** The renderer init completes without ever waking its worker.
`sub_82178F60` (the spawn-prep) ALWAYS returns 0 (literal `addi r3, r0, 0` at 0x8217919C). And `sub_82178E50`'s spawn condition is `bc 4, 4*cr6+eq` which means **branch on NOT-EQ → branch is NOT taken when r3=0** → fall through to spawn. So thread is always spawned. ✓ Matches the 18 ExCreateThread observation.
## Significant new insight: the throw might be REQUIRED for proper init
Sub_82178F60 (in both r4=0 and r4=1 paths) calls into `sub_82175F10` (the throw site we silenced). With proper C++ SEH, the throw at sub_82454770(lhs=0x828F3F68) would propagate up: sub_82454770 → sub_82175F10 → sub_82178F60 → sub_82178E50 → silph::OnInit → ... — looking for a `__try`/catch.
Our current "fix" forces sub_82454600 to return valid, AVOIDING the throw entirely. But if the catch handler is responsible for **lazy registration** (creating the missing object AND signaling its event), our fix bypasses the registration logic. Result: object pretends valid → workers spawn → workers wait for signal that never comes.
Canary "swallows" the throw similarly to us, but Canary also doesn't implement SEH dispatch (per the `xboxkrnl_debug.cc:131-151` comment "TODO(benvanik): unwinding. This is going to suck."). So Canary EITHER:
- (a) hits a different upstream HLE that pre-registers the object (no throw needed)
- (b) faces the same deadlock but progresses anyway (somehow)
Given our audit shows no signal-fires-but-fails pattern, hypothesis (a) is most likely. The "missing pre-registration" must come from some HLE we implement differently.
## REVISED recommendation
The throw fix from [project_xenia_rs_sylpheed_throw_fix_2026_04_29.md](project_xenia_rs_sylpheed_throw_fix_2026_04_29.md) is now SUSPECT — it may mask the real bug. Two paths forward:
### Path A: Roll back the throw fix and implement minimal SEH dispatch (Branch B from original plan)
This is the multi-day work originally deferred. Implement enough of `__CxxFrameHandler3` + .pdata/.xdata parsing to dispatch the catch. If the catch handler (when actually run) signals events and registers objects, this resolves the deadlock at root.
### Path B: Find the upstream HLE difference (Stage 2 Branch A from original plan)
Identify what UPSTREAM HLE Canary returns differently such that the lhs=0x828F3F68 lookup succeeds WITHOUT needing the throw. The key test: in our environment, what populated the BST registry's static-data range at 0x828F3F68? Find the function that registers `0x828F3F68` in the BST. Trace its callers. Find where it WOULD have been called but wasn't. The missing call is the upstream HLE divergence.
Path B is the original recommendation and remains the cleanest fix. We should:
1. Search xrefs for `bl sub_82454580` (BST insert) where the inserted address ends up being `0x828F3F68`. This is hard because the address is data-flow dependent.
2. Easier: search for code that loads `0x828F3F68` as an immediate/constant. If found, that's the "should-register-this" site. Trace why it doesn't run.
## Decisive finding: 0x828F3F68 IS registered just before validation
Searched xrefs to `0x828F3F68`. Found 5 references:
- `sub_82175E68` (twice, at 0x82175EA0 + 0x82175EC4) — **the BST REGISTRATION site**
- `sub_821766A0` (twice, at 0x821766C4 + 0x821767C8) — registers a list of 16 elements + 0x828F4068
- 0x8284C9C4 — singleton trampoline data
**`sub_82175E68` is called from sub_82178F60 at instruction `0x82179134`, EIGHT instructions before the throw site call to `sub_82175F10` at `0x82179144`.** Same function, same thread, sequential execution. So:
```
sub_82178F60:
...
0x82179134: bl sub_82175E68 ; REGISTERS 0x828F3F68 in BST
0x82179144: bl sub_82175F10 ; VALIDATES 0x828F3F68 (PPC says: not in BST → throw!)
```
The throw shouldn't fire normally. The PPC's validator failing to find 0x828F3F68 in the just-populated BST is the PRIMARY bug. **Our throw fix is masking the primary bug, not fixing it.** And the same memory-coherence (or whatever-else) bug that prevents the validator from seeing the registration likely also prevents OTHER reads from seeing OTHER writes — which explains why event 0x1004 never wakes its waiter (the worker's poll-bit might not see the producer's set).
This makes the **paradox from [project_xenia_rs_sylpheed_throw_2026_04_28.md](project_xenia_rs_sylpheed_throw_2026_04_28.md) the load-bearing problem**: PPC reads not seeing PPC writes from the same thread.
## Strongly recommended next direction
**Investigate the memory-coherence paradox at the emulator level**. Build a smaller reproducer:
1. In `step_block` (the interpreter loop), trace one specific BST node's `[+8]` slot for the failing thread. Log every WRITE to address `0x40249F68` and every READ from it, with PC + instruction.
2. Cross-check: did the PPC actually execute a write to `0x40249F68` between enter-CS and the validator's read of that slot? If no write, our Rust CEIL is wrong about it being there. If yes, there's a write-visibility bug.
3. If write-visibility bug: candidates are (a) the basic-block cache pre-decoding stale instructions, (b) memory MMU bug for that page, (c) instruction-cache vs data-memory aliasing.
This is a TRACE/INSTRUMENTATION job, not pure static analysis. It's what should have been the focus of the previous session but was deferred.

96
migration/claude-memory/project_xenia_rs_sylpheed_stage3_2026_04_29.md Normal file
View File

@@ -0,0 +1,96 @@
---
name: Sylpheed post-throw-fix Stage 3 thread-state analysis (2026-04-29)
description: Detailed thread state at -n 4B post-throw-fix. 18 workers spawn, throw fully silenced, but renderer is deadlocked on unsignaled events. Stage 3 gate (draws > 0) NOT met.
type: project
originSessionId: c44cbfc2-438f-45c9-996c-06eddf9dcb93
---
## Run results post-throw-fix (-n 4B)
```
swaps=2, draws=0, resolves=0, packets=1.7B, imports=46M, RtlRaiseException=0
VdSwap=2, gpu.interrupt.delivered{source=0}=26630 (vsync), source=1: 2
NtSetEvent=3334, NtCreateEvent=394, NtWaitForSingleObjectEx=1.5M
ExCreateThread=18, scheduler.spawn.ok=18
```
The single throw is fully silenced; only ONE `VALIDATOR forced` log line per run (call_n=32, lhs=0x828F3F68). Game progresses to spawning all 18 workers + opening renderer resource files (`hidden/Resource3D/ptc_pack.xpr`, `Common.xpr`).
## Thread state at -n 500M (deadlock snapshot)
3 threads `Ready`: tid=1 (main, polling loop), tid=12, tid=15, tid=17, tid=7, tid=19. **10 threads `Blocked` on events/semaphores. 2 suspended (tid=8, 9). 1 exited (tid=11)**.
### Blocked-on-WaitAny worker map
| tid | hw | entry func | waits on | object state |
|---|---|---|---|---|
| 2 | 5 | sub_82181830 | handle 0x100c | Event(sig=false, **mr=true**) |
| 3 | 3 | sub_8245A5D0 | handle 0x1014 | Semaphore(0/maxint) |
| 4 | 3 | sub_82450A28 | handles 0x1038, 0x103c (deadline=1600) | Event mr=false + Semaphore 0/max |
| 5 | 5 | sub_82457EF0 | handles 0x10b0, 0x10b4 (deadline=1600) | Event mr=false + Semaphore 0/max |
| 6 | 2 | sub_824CD458 | handle **0x42450b5c** (deadline=3000) | Event(sig=false, **mr=true**) — heap-pointer object |
| 10 | 5 | sub_82178950 | handle 0x1004 | Event(sig=false, **mr=true**) |
| 13 | 1 | sub_822C6870 | handle 0x12f8 | Semaphore(0/maxint) shared with tid=14 |
| 14 | 3 | sub_822C6870 | handle 0x12f8 | (same) |
| 16 | 4 | sub_82170430 | handle 0x15e4 | Event(sig=false, **mr=true**) |
| 18 | 3 | sub_823DDB50 | handles 0x15fc, 0x01000000 | Event mr=false + something |
### What's most suspicious
Four `mr=true` events with `sig=false` waiters that never get signaled:
- 0x1004 (tid=10, sub_82178950)
- 0x100c (tid=2, sub_82181830)
- 0x15e4 (tid=16, sub_82170430)
- 0x42450b5c (tid=6, sub_824CD458) — guest heap-ptr "kernel object" form
These are in the 0x82170-0x82181 / 0x824CD address ranges — Sylpheed's renderer worker entries.
## tid=1 (main) state analysis
PC=0x822F1E00 in [sub_822F1AA8](xenia-rs/sylpheed.db) — a **frame-loop / poll loop**. The flow:
1. Check bit 3 of `r30[0]` (frame-ready flag).
2. If set, do timing work via thunk `bl 0x8284E45C` (KeQueryPerformanceCounter or similar).
3. Loop back to 0x822F1BCC.
This is the game's normal main loop. Bit 3 of r30[0] is the "running" / "frame ready" flag, polled in a tight loop. It's healthy — main is just waiting for a frame to be ready.
## Hypothesis: the Sylpheed renderer signal-chain has multiple breaks
Even with the throw fixed, the workers can't progress because their wakeup events are tied to GPU/frame events that depend on:
1. Draws completing (won't happen until renderer init finishes)
2. Renderer init finishing (won't happen until workers process their queues)
3. Workers processing queues (won't happen until events are signaled)
This is a cascade. The throw fix was necessary but not sufficient.
## Side observation — `gpu.interrupt.delivered{source=1}=2` matches `VdSwap=2`
Source-1 interrupts (likely "swap complete") fire only on VdSwap. They're a chicken-and-egg dependency on draws.
## Recommended next directions (in priority order)
### Option A — Find the missing producer for one specific event
Pick the simplest cascading dependency. Suggestion: tid=10's wait on event 0x1004 (mr=true). Trace:
1. Identify guest function that calls `NtCreateEvent` to create handle 0x1004 (it's an early event since handle is small — likely first or second event created).
2. Find xrefs from same function to `NtSetEvent` — that's the SHOULD-signal site.
3. Compare which guest function should call NtSetEvent for handle 0x1004 vs what currently runs.
### Option B — Trace per-handle NtSetEvent counts
Add per-handle telemetry to `nt_set_event` to dump which events fire how many times. Cross-reference with the blocked-on list. Identify events that are CREATED but never SIGNALED.
### Option C — Compare with Canary
Run the same boot path under xenia-canary with logging enabled. See which NtSetEvent / KeSetEvent calls fire on Canary that don't fire on us. The diff is what we're missing.
### Option D — Accept Stage 3 gate is unreachable without a multi-day investigation
The cascade structure of Sylpheed's renderer init means small fixes won't help; we need to identify the FIRST event in the chain that needs to fire. That's not visible from a single-session diagnostic. Defer Stage 3 / 4 to a focused multi-day investigation.
## Files unchanged this session
The throw-fix from [project_xenia_rs_sylpheed_throw_fix_2026_04_29.md](project_xenia_rs_sylpheed_throw_fix_2026_04_29.md) remains in place. No code changes this session — only diagnostic runs.
## Open question for the user
Take Option A on tid=10/event 0x1004 as a focused next session, or step back and pursue Option C (Canary diff)?

106
migration/claude-memory/project_xenia_rs_sylpheed_throw_2026_04_28.md Normal file
View File

@@ -0,0 +1,106 @@
---
name: Sylpheed VdSwap=2 plateau — C++ throw diagnostic landed (2026-04-28)
description: One-shot RtlRaiseException stack-walk diagnostic + identified the std::runtime_error("lhs is not valid instance") that gates Sylpheed renderer init
type: project
originSessionId: c44cbfc2-438f-45c9-996c-06eddf9dcb93
---
## Problem
Sylpheed boots cleanly to VdSwap=2 then plateaus indefinitely. At -n 100M / 500M:
- `swaps=2` unchanged across both
- `packets≈206 M` but `draws=0, resolves=0, render_targets=0, shader_blobs=0, texture_decodes=0`
- vsync ISRs scale linearly (628 / 3,295), `unimpl=0`
- 18 worker threads spawn; renderer-side workers park on `WaitAny` on per-thread events nobody signals
## Stage-1 diagnostic landed
[`xenia-rs/crates/xenia-kernel/src/exports.rs:1878`](xenia-rs/crates/xenia-kernel/src/exports.rs#L1878) `rtl_raise_exception` rewritten to:
1. Use the correct EXCEPTION_RECORD layout (`info[0..]` starts at `+0x14`, not `+0x18`; old comment was off by 4 — Canary parity at `xenia-canary/src/xenia/kernel/kernel.h:227-236`).
2. Read `info[0]` (magic, expected `0x19930520`).
3. On first fire of code `0xE06D7363`, walk the PPC frame chain ~6 levels using the back-chain convention (`prev_sp = mem[sp]`, `saved_lr = mem[prev_sp - 8]`).
4. Decode the runtime_error object's `_Mystr` (offset `+0x0C` per the destructor disasm at `sub_8216DBC0`). Layout: `vtbl(0), _Mywhat(4), _Mydofree(8), _Mystr(0xC)`.
5. One-shot via new `KernelState::cxx_throw_logged: bool` (initialized in `with_gpu`).
Diagnostic added a `cxx_throw_logged` field to [`xenia-rs/crates/xenia-kernel/src/state.rs`](xenia-rs/crates/xenia-kernel/src/state.rs) struct (after `thunks_by_ordinal`).
## What the diagnostic shows
Single throw at ~1.2s on tid=1. Stack walk:
```
L0: fp=0x700ff2a0 lr=0x82612b50 → _CxxThrowException +0x70 (after bl RtlRaiseException)
L1: fp=0x700ff350 lr=0x825f2444 → __CxxThrow wrapper sub_825F23D8 +0x6C
L2: fp=0x700ff3e0 lr=0x824547e8 → THROW SITE: sub_82454770 +0x78
L3: fp=0x700ff4c0 lr=0x82176134 → caller: sub_82175F10 +0x224
L4: fp=0x700ff600 lr=0x82179148 → caller: sub_82178F60 +0x1E8
L5: fp=0x700ff6e0 lr=0x82178ee4 → caller: sub_82178E50 +0x94
L6: fp=0x700ff760 lr=0x82173a4c → caller: unnamed fn @ 0x82173990 +0xBC
```
Throw call at PC `0x824547e4` (`bl 0x825F23D8`). Throwinfo at `0x82117388`. Class is **`std::runtime_error`** (verified via `CatchableTypeArray @ 0x8211737c → TypeDescriptor @ 0x8289aed4` containing mangled `.?AVruntime_error@std@@`).
**Message string literal**: `0x820B0000 + 22160 = 0x820B5690` = `"lhs is not valid instance"`. Adjacent at +22188 = `"rhs is not valid instance"`. Read directly from the .pe via Python (object decode in the diagnostic returned mysize=0/myres=25/heap_ptr=0x48bd64d1 — the basic_string layout differs from MSVC-default and needs re-investigation if precise decode is wanted; the literal is unambiguous from the disassembly).
## Subsystem identified
L6's enclosing function (no entry in `functions` table — gap; starts at `0x82173990` with `mfspr r12, LR; stwu r1, -288(r1)` prologue) processes config sections by name. Literal cluster around `0x820A1860..0x820A18B0`:
- 6044, 6056=`SYSTEM`, 6064=`ENTRY_POINT`, 6076, 6088=`'silph::Silph::Impl::OnInit - RenderDevice initialized. spend %d ms.\r\n'`
- 6264=`SOUNDS`, 6272=`FILES`, 6280=`STAGES`, 6288=`PARAM`, 6296=`PATH`, 6304=`SETTINGS`, 6320=`'unnamed_namespaces::...::BankSlots::get_bgm_data_area - Failed : previous bgm is available. call release_bgm()'`
So we're inside **`silph::Silph::Impl::OnInit`**'s config-tree walker.
## What `sub_82454770` actually does
It's a generic guarded list-swap helper. Pattern: `if (!is_valid_instance(lhs)) throw runtime_error("lhs is not valid instance"); if (!is_valid_instance(rhs)) throw "rhs ..."; if (*lhs != *rhs) swap_nodes(lhs, rhs);`. Has 29 guest callers across many subsystems (sub_82175F10, sub_82176880, sub_82180708, sub_82187...A0, sub_821A5F10, etc.) — it's a Sylpheed-internal utility, not a single subsystem.
`sub_82454600` (the validator) walks an intrusive linked list of "registered instances" guarded by a critical section at `0x828F3DA8`. Each node has `is_valid` byte at `+17` and a key/range field at `+12`. The list is initialized lazily by `sub_82454498` (registry singleton getter) which Initializes the CS with spin=256 + creates a sentinel head + flips the init flag at `0x828F3EB0`.
Reading the validator more carefully: it walks and compares `node[+12]` against `r30` (lhs) using `subfc/subfe` — a range-membership test. So **lhs being "invalid" means it's not inside any registered range**.
## Canary parity
`xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_debug.cc:131-151` — Canary's `RtlRaiseException` is also a stub (only handles `0x406D1388` thread-name + `0xE06D7363` C++ exception, logs and returns). `RtlUnwind`/`RtlVirtualUnwind`/`RtlLookupFunctionEntry` are exported but have **no implementations**. Comment: `// TODO(benvanik): unwinding. This is going to suck.` So Canary's behavior is identical to ours on this code path. Either:
- (a) Canary doesn't trip this throw on its boot (some upstream HLE returns a value that keeps lhs in the registered range), OR
- (b) Canary trips the same throw, swallows it the same way, and the post-throw state is good enough that the renderer still progresses.
We don't yet have a concrete data point that distinguishes (a) from (b).
## Why current swallow plausibly breaks the renderer
After our `RtlRaiseException` returns, `_CxxThrowException` returns to `sub_825F23D8` (the `__CxxThrow` wrapper), which returns to the throw-site function `sub_82454770` at PC `0x824547e8`. Post-throw code in the throw-site function then **runs as if the throw didn't happen**. In `sub_82175F10` specifically, the post-bl code at `0x82176134` is `stw r18, 0(r25)` — an unconditional store via `r25` whose validity was not yet established. With swallow, this store may corrupt memory at an arbitrary address.
Real C++ behavior would be: `bl _CxxThrowException` never returns; control transfers to the matching catch handler via .pdata/.xdata-driven SEH dispatch. We don't implement that (Canary doesn't either).
Only **one** throw fires (`kernel.calls{name=RtlRaiseException} = 1` at -n 100M and -n 500M). So the corruption happens once during early boot and persists.
## Next-session candidates (in priority order)
1. **Fix the runtime_error decoder.** The current diagnostic gets the message via `_Mystr` at `+0x0C` but the basic_string layout returned mysize=0/myres=25 — wrong field order or different size_t alignment. Dump 32 bytes of the object via `mem.read_bytes` and log as hex to nail the layout once. The literal is already known from disasm (0x820B5690) so this is just for completeness.
2. **Identify why lhs is "not in any registered range"**. Two angles:
- **Trace `sub_82454498`** (the registry singleton) — log every node added to the intrusive list (instrumented hook on the `bl 0x82454498` from any of its ~hundreds of callers). See what ranges it tracks, compare against the `r30` value at the throw moment (`r30 = 0x???` — wasn't dumped this session, add to L0 frame log).
- **Trace `sub_82454770` itself** — log each call's `lhs/rhs` and whether the validator passes. Identify the FIRST call that fails. Look at what allocated `lhs` upstream.
3. **Implement minimal SEH dispatch** as a backstop. Parse the XEX `.pdata` (RUNTIME_FUNCTION table) + `.xdata` (UNWIND_INFO + `__CxxFrameHandler3` blob with magic `0x19930520`). For the throw-site function (`sub_82454770`), find the calling function's try-block map; on match, restore non-volatile regs + transfer to catch funclet. This is multi-day work but is the proper fix for any future C++ throw.
4. **wgpu→ShadowEdram readback** is still deferred (no point until draws fire).
## What stays
- `cxx_throw_logged` field in `KernelState` and the corresponding init in `with_gpu`.
- Rewritten `rtl_raise_exception` with correct EXCEPTION_RECORD offsets, `info[0]` magic capture, 6-level frame walk, and runtime_error decoder (still slightly off — see point 1 above).
## Verification command
```bash
./target/release/xenia-rs check "../Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso" -n 100M 2>&1 | grep -E "cxx_throw|RtlRaiseException"
```
## Files touched
- [xenia-rs/crates/xenia-kernel/src/state.rs](xenia-rs/crates/xenia-kernel/src/state.rs) — added `cxx_throw_logged: bool` field + init.
- [xenia-rs/crates/xenia-kernel/src/exports.rs:1878](xenia-rs/crates/xenia-kernel/src/exports.rs#L1878) — replaced `rtl_raise_exception` with diagnostic version.
No regressions introduced; the new code only fires on the first MSVC C++ throw; everything else is unchanged.
## Open question for the user
Whether to invest in (a) tracing `sub_82454498`/`sub_82454770` to find the missing registration (one focused session), or (b) implementing minimal SEH dispatch (multi-session). The plan file at `/home/fabi/.claude/plans/yes-take-any-action-noble-dragon.md` covered both as Branch A vs Branch B.

89
migration/claude-memory/project_xenia_rs_sylpheed_throw_fix_2026_04_29.md Normal file
View File

@@ -0,0 +1,89 @@
---
name: Sylpheed C++ throw silenced via r31 override (2026-04-29)
description: Force-corrected sub_82454600 return value at leave-CS HLE — throw eliminated but draws=0 plateau persists due to downstream blockers
type: project
originSessionId: c44cbfc2-438f-45c9-996c-06eddf9dcb93
---
## Outcome
The single `std::runtime_error("lhs is not valid instance")` throw at PC `0x824547e4` is **fully silenced** by overriding `ctx.gpr[31]` from 32 → 14 in `rtl_leave_critical_section` whenever:
- `cs_ptr == 0x828F3DA8` (BST registry)
- `ctx.lr == 0x824546C8` (leave-CS return addr in sub_82454600)
- Our Rust CEIL search finds the lhs in the BST (`match_found=true`)
- BUT the PPC computed `r31=32` (no-match)
**Verification command** (-n 100M, 500M, 1B all show same):
```
./target/release/xenia-rs check sylpheed.iso -n 1000000000 --out /tmp/d.json
```
Result: `kernel.calls{name=RtlRaiseException}` is **absent from metrics summary** (was 1 before). One `VALIDATOR forced` log line for call_n=32, lhs=0x828F3F68.
## What unlocks vs. what doesn't
**Unlocked** (post-fix, -n 200M..1B):
- Game now loads renderer resources: `NtReadFile` from `hidden/Resource3D/ptc_pack.xpr`, `Common.xpr`
- All 18 `ExCreateThread` calls spawn (was already spawning before fix, but now to-completion)
- `NtWaitForSingleObjectEx`/`NtWaitForMultipleObjectsEx` counts grow to ~500K+/~325K+ (heavy waiter activity)
- packets=445M at -n 1B (increasing) — ring traffic flows
**Still blocked** (Stage 2 gate NOT met):
- `draws=0`, `swaps=2`, `resolves=0` — same as before the fix
- No PM4_DRAW_INDX* commands issued by guest
- All 18 workers eventually park; nobody signals their events
## The unresolved paradox
**Symptom**: At enter-CS time AND leave-CS time, our Rust CEIL search successfully finds node 0x4024A9C0 with key=0x828F3F68 in 17 steps. Yet between those two HLE invocations, the PPC's identical traversal returns `r31=32` (no match).
**What was verified** (still doesn't explain it):
- Algorithm parity: PPC's CEIL (sub_82454600 disasm) and our Rust use identical child offsets `[+0]=left`, `[+8]=right`, `key=node[+12]`, with identical comparison directions confirmed against TreeInsert (sub_8235FC98) at addresses 0x8235FC98..0x8235FD40.
- BST root is consistent: `sentinel_ptr=0x402118A0`, `sentinel[+4]=0x4021DB60`, `root_b17=0` at both enter-CS and leave-CS.
- No memory writes between the two HLE calls touch any BST node addresses (heap 0x4021xxxx..0x4024xxxx). Our enter-CS HLE writes only to CS struct fields (0x828F3DB8/BC/C0).
- Lockstep mode (no `--parallel`) → no concurrency. `park_current` is lazy (sets `state=Blocked`), but `worker_prologue` checks state next round, so a parked thread can't execute more PPC instructions.
- Endianness: irrelevant since the same `read_u32` semantics produce consistent results for all calls 0..31 (which succeed).
**Right-spine traversal at enter-CS for the failing call**:
```
step 0: 0x4021DB60 key=0x828E6878 → right
step 1: 0x40229B60 key=0x828EA2D8 → right
... 11 more steps with keys monotonically increasing ...
step 12: 0x40249F60 key=0x828F2F68 → right (next is 0x40249F68 → 0x4024AA20)
step 13: 0x4024AA20 key=0x828F3F98 → LEFT (candidate=0x4024AA20)
step 14: 0x40211C80 key=0x828F3EF8 → right
step 15: 0x4024A9E0 key=0x828F3F78 → LEFT (candidate=0x4024A9E0)
step 16: 0x4024A9C0 key=0x828F3F68 → LEFT (candidate=0x4024A9C0, EXACT MATCH)
step 17: 0x402118A0 b17=1 → STOP. Final candidate=0x4024A9C0, key=0x828F3F68.
```
Both PPC and our Rust should follow this exact path. The PPC must be reading `mem[0x40249F68]` and getting something other than `0x4024AA20`, but no concurrent code touches that address.
## sub_82454600 return-value computation
After leave-CS at `0x824546C4`, the post-CS code at `0x824546C8..0x824546D4` derives `r3` (return value) from `r31` (= cntlzw of candidate-sentinel diff):
- `r31 in [0,31]` (match found): r3=1 (valid)
- `r31 = 32` (no match): r3=0 (invalid → triggers throw)
Setting `r31=14` in our HLE makes r3=1, sub_82454600 returns valid, sub_82454770 proceeds past the lhs check. r31=14 is what `cntlzw(0x4024A9C0 - 0x402118A0) = cntlzw(0x39120) = 14` would produce naturally.
## Files touched (2026-04-29)
- [xenia-rs/crates/xenia-kernel/src/exports.rs](xenia-rs/crates/xenia-kernel/src/exports.rs)
- `rtl_enter_critical_section` (line 1634): added enter-CS diagnostic + Rust CEIL search for the failing lhs (verbose only when `lhs == 0x828F3F68`).
- `rtl_leave_critical_section` (line 1696): added r31 override when `match_found=true && ctx.gpr[31]==32`.
## Stage status (per plan `yes-take-any-action-noble-dragon.md`)
- **Stage 1 (diagnose throw)**: ✅ Complete (prior session).
- **Stage 2 (eliminate throw)**: ⚠️ Throw silenced, but `draws > 0` gate NOT met. The throw was real, but it was not the *single* load-bearing fix. Downstream renderer initialization still parks on unsignaled events.
- **Stages 3/4/5**: still pending.
## Recommended next direction
The throw fix is a workaround, not a root-cause fix. The PPC-vs-Rust BST traversal paradox is **unexplained** and worth one more session of focused debugging if a real explanation matters (it might reveal a memory-system bug that's causing OTHER subtle bugs). Options:
1. **Accept the workaround, push forward to Stage 3**: With draws still 0, find the next blocker (likely a missing event signal or HLE divergence). Workers parking on `WaitAny` of per-thread events suggests an event-set HLE that's not firing in our impl but does on Canary.
2. **One last attempt at the paradox**: Add per-instruction PPC-level tracing for instructions 0x82454638..0x82454668 (the traversal loop) when r30=0x828F3F68, to log what the PPC actually reads at `lwz r11, 8(r11)` for the critical step 12 → step 13 transition (our Rust reads `mem[0x40249F68]=0x4024AA20`; PPC must be reading something else).
## Open question for the user
Continue Stage 3 (find next blocker) or take another shot at the paradox? The workaround is stable: only fires once, only for the specific known-good case (Rust CEIL confirms the node IS in the BST), no false-positive risk. We can ship it as-is and treat the paradox as a known-issue.

69
migration/claude-memory/project_xenia_rs_ui.md Normal file
View File

@@ -0,0 +1,69 @@
---
name: xenia-rs --ui architecture (stable facts)
description: Threading/bridge design, shader pipeline, GPU integration, HUD — stable across sessions. History + live state in `project_xenia_rs_current_state.md`.
type: project
originSessionId: 1e348be4-7f53-438a-9c1b-e0c2fcb7ec0d
---
## Threading & bridge
`exec --ui` runs winit on the main thread and the scheduler/interpreter on a worker thread. Cross-thread communication: `Arc`-shared atomics + `EventLoopProxy` user events. `KernelState::ui: Option<UiBridge>` carries closures that (a) read host gamepad and (b) post `SwapInfo` + frontbuffer bytes to the UI. `GuestMemory` stays pinned to the interpreter thread; only cooked bytes cross.
**Why:** winit 0.30+ `ApplicationHandler` requires the main thread and wgpu's Surface is tied to `Window`. The interpreter is single-threaded (6 cooperative HW slots); making it multithread-safe would require `Arc<RwLock<GuestMemory>>` on every guest instruction.
**How to apply:** when adding cross-thread UI state, extend `SwapInfo` (post-swap) or add an atomic on `UiHandles` — don't reach across threads directly.
## GPU pipeline (P2–P7 stable)
- **`xenia-gpu::GpuSystem`** — one per `KernelState`. Owns the `RegisterFile`, the `RingBufferView` (+ IB stack for nested `PM4_INDIRECT_BUFFER`), the `TextureCache` / `RenderTargetCache` (P4/P5), and the `GpuMmio` atomic mailbox exposed via the `0x7FC8_0000` MMIO aperture (Canary `graphics_system.cc:141`). Per scheduler round: `sync_with_mmio()` then `execute_one()` of whatever's ready.
- **Type-3 packet coverage**: every non-draw Type-3 opcode is implemented (NOP, INDIRECT_BUFFER[_PFD], WAIT_REG_MEM, REG_RMW, REG_TO_MEM, MEM_WRITE, COND_WRITE, EVENT_WRITE[_SHD/_EXT/_ZPD], SET_CONSTANT[2], SET_SHADER_CONSTANTS, LOAD_ALU_CONSTANT, IM_LOAD[_IMMEDIATE], CONTEXT_UPDATE, INVALIDATE_STATE, VIZ_QUERY, ME_INIT, SET_BIN_MASK/SELECT, INTERRUPT, XE_SWAP). `DRAW_INDX*` captures `DrawState` + `ProcessedPrimitive` + metrics.
- **WGSL shader interpreter (P3b/c + P7)**: `xenia-gpu::ucode` decoder + `pack_for_wgsl` dense layout; `xenos_interp.wgsl` (~465 LOC) implements the CF walker + 13 vec ALU ops + 6 scalar ops + R32G32B32A32_FLOAT vertex fetch + texture sampling. `XenosPipeline::new` builds two bind groups; uploads shader+constants+vertex before each batch in `dispatch_xenos_draws`. P7 added a direct Xenos→WGSL translator for when shader-bug isolation is needed.
- **Texture cache (P5)**: page-version invalidated via `GuestMemory::page_version`. Formats supported: `K8888`, `K565`, `Dxt1`, `Dxt2_3`, `Dxt4_5` (M5). Host side `texture_cache_host.rs` maps each to `Rgba8Unorm`/`Bc{1,2,3}RgbaUnorm` with format-aware `bytes_per_row`.
- **Render target cache (P4)**: EDRAM resolve handler `handle_event_initiator` wired into all four `PM4_EVENT_WRITE*` variants. On event code 15 (`TILE_FLUSH`), snapshots `RB_COPY_*` into `last_resolve`, bumps `stats.resolves_total`. Actual EDRAM→memory byte copy still deferred.
## MMIO aperture (stable)
- Base `0x7FC8_0000`, mask `0xFFFF_0000`, size `0x0001_0000`. Install via `MmioRegion` on `GuestMemory`.
- Registers served (others trace+zero): `CP_RB_WPTR`, `CP_RB_RPTR`, `CP_INT_STATUS`, `CP_INT_ACK` (0x071D, write-echo), `D1MODE_VBLANK_VLINE_STATUS` (0x1951 / byte offset `0x6544`, W1TC on bit 0).
- Bit 0 of `D1MODE_VBLANK_VLINE_STATUS` is set by the app main loop on every synthetic vsync tick; Sylpheed's callback `rlwinm. r,r,0,31,31; bc 12,2,skip` gates all vsync work on it.
## Scheduler + interrupts
- **`HwState` variants**: `Idle`, `Ready`, `Blocked(BlockReason)`, `Exited(code)`, `ServicingIrq(BlockReason)`. `ServicingIrq` is used by the graphics-interrupt injector to stash a block reason while running the callback; `wake()` and `round_schedule` both treat `ServicingIrq` as runnable.
- **Graphics interrupt injection** (post-M8): `try_inject_graphics_interrupt` picks any non-`Idle`/`Exited` HW slot (prefers `Ready`, falls back to `Blocked`). `InterruptState::injected_hw` tracks which slot ran the callback. The LR-sentinel return path restores pre-injection ctx and re-blocks with the stashed reason (unless a `wake()` during the callback cleared it).
- **Deadlock recovery**: when all live threads are `Blocked/Idle/Exited` and no timer is pending, force-wake every blocked thread with `STATUS_TIMEOUT` in `gpr[3]`. `scheduler.deadlock_recoveries` counter tracks this.
- **Main thread exit is NOT a halt**: when `tid=1` hits `LR_HALT_SENTINEL` we mark it `Exited` and continue; the outer loop halts only when `has_live_thread()` is false. Sylpheed's design spawns workers then returns from main.
## HLE primitives (stable)
- **Pseudo-handle resolution** `resolve_pseudo_handle(state, h)`: `0xFFFFFFFE` → current thread handle, `0xFFFFFFFF` → 0, others pass through. Called at top of every `Ob*`/`Nt*Wait*` export.
- **PKEVENT shim** `ensure_dispatcher_object(state, mem, ptr)`: `Ke*` sync functions take `PKEVENT` pointers; first touch reads Xenon DISPATCHER_HEADER (type byte + SignalState at +4 + Limit at +0x10 for semaphores) and mints a shadow `KernelObject` keyed by the pointer. `refresh_pkevent_shadow_from_guest` re-syncs `SignalState` on each wait.
- **WaitAny handle-index return**: Canary's `WaitMultiple` returns `STATUS_WAIT_0 + index` for WaitAny. `do_wait_multiple` matches; `set_wake_status_for_waitany` updates `gpr[3]` on wake.
- **I/O completion signaling**: `signal_io_completion_event(state, event_handle)` fires at every completion path of `NtReadFile`/`NtWriteFile` (r4 = event).
- **Empty-path / root-device opens** (`NtCreateFile("game:\")` etc.): synth a zero-byte `KernelObject::File` with empty `path`. `NtQueryInformationFile` class 5 reports `Directory=1` for empty/`/`/`:`-tail paths; class 34 (`FileNetworkOpenInformation`, 56 B) reports `FILE_ATTRIBUTE_DIRECTORY` at offset +48.
## HUD
6 rows, well-spaced, cyan accents:
1. Title + uptime + instr/kIPS (live counter via `instructions_counter` atomic).
2. Swaps.
3. GPU stats (packets, draws_total, resolves_total, interrupts).
4. Last-draw prim/verts.
5. Pad state.
6. Render path: `xdispatch: xlated=N interp=M xlated-pipelines=P tex-cache=T fb=WxH`.
One-shot `tracing::info!` latches: "first Xenos draw dispatched" and "first translator pipeline compiled".
## Observability defaults
Silences wgpu/winit/naga/gilrs at `warn` (wgpu at `error`). Override via `--log-filter='info,wgpu_core=trace'` during bring-up. `--trace-chrome PATH` captures Chrome/Perfetto trace; `--profile PATH.svg` emits a flamegraph.
## Interpreter performance (post-Tier-3)
~10 MIPS end-to-end on Sylpheed. Three wins stacked: de-hot-patted `metrics::counter!` per instruction; direct-mapped 64k `DecodeCache` keyed by PC with page-version invalidation; `Debugger::wants_hooks()` short-circuit + `trace_enabled = false` default (previous O(n²) `Vec::remove(0)` on the trace log was the real bottleneck, not `metrics`).
**Deferred Tier 4** — threaded-code dispatch / JIT. Only worth doing after the shader translator + HLE coverage gaps narrow; fast-but-wrong produces fast-wrong output.
## Phase history
Complete roadmap P1–P8 + perf Tiers 1–3 + first-pixels M1–M9 all landed. Details deliberately elided here — they're in the individual commit messages and the `project_xenia_rs_current_state.md` next-steps file. This doc stays focused on stable facts a new session needs before touching the code.

Some files were not shown because too many files have changed in this diff Show More