2 Commits

Author	SHA1	Message	Date
Kevin	3cbe6c1cde	kernel-bless: publish install-slot ranges so patched BIOS bodies run native ... The BIOS exception handler ran interpreted for the life of every process, 1.22 billion instructions and 44.6% of all interpreted work in Breath of Fire III, even though it is compiled and even though the stub that unblessed it sat at exactly the address bios/SCPH1001.toml already declared as an install slot. Two mechanisms existed and did not compose: the emitter hooked the declared slot PC, while the runtime's bless verifier memcmp'd the whole body including that slot, so the body was MISMATCH forever and native code never reached the hook. Three parts, none of which pays off alone: 1. Publish the declared ranges to the runtime. The emitter emits a PsxKernelPatchRange table next to the kernel body table and routes it through the backend descriptor; the bless verifier compares a body in segments that skip them. CLEAN now means "every byte outside every declared range still matches ROM", which is the claim the native code actually depends on. 2. Generalise the slot model to what the patches are. The old model assumed a 4-word lui/addiu/jalr/nop stub written over ROM zeros and fired on `word != 0`. Measured against both images, only one of five observed shapes fits: patchers also plant a `jr` over real ROM instructions, rewrite an 11-word prologue and insert an `mfc0 Cause`, and NOP out a driver routine. A slot is now a range with a length and an explicit `resume` (jalr / fallthrough / none), detected by comparing every word against its ROM-baked value. 3. Hand back from the interpreter at the range end. Kernel page 0 is permanently dirty, because the handler saves registers there on every exception, so straight-line interpretation would run the whole function after the patch. The emitter registers the resume PC as a continuation key and dirty_ram_interp surfaces there. A PC inside a declared range must never be a native dispatch key: the compiled bytes there are not what executes. Seven pre-existing jal-return continuations violated that and wedged the boot at frame 0 in an infinite dispatch loop (OpenBIOS RAM 0x357C). The emitter now drops continuation keys inside a range so dispatch misses through to the interpreter, and refuses to emit if a range covers a function entry, which would silently remove a callable function instead. Both profiles declare their measured ranges, and SCPH1001.toml finally pins [program.image] sha256 to v2.2 (CRC32 37157331) so a v2.0 dump refuses to generate rather than producing phantom discovery gaps. Measured on Breath of Fire III (SLPS-00990, Psy-Q SDK 3.70), headless, matched frames, PSX_KERNEL_PATCH_RANGES=0 for the OFF side: OpenBIOS SCPH-1001 v2.2 bless mismatch 21 -> 0 74 -> 0 kernel bodies -87.7%/frame -97.8%/frame all interp insns -42.6%/frame -94.2%/frame The residual kernel-body work is exactly declared-words x entries on every range, so nothing leaks past the hook. The A0/B0/C0 vector trampolines are unchanged (+0.2%, noise): the profile excludes them by design and they are a separate job. Card read traces are byte-identical across the A/B on both images, all 32 entries, which exercises the two ranges that replace the kernel's card handler. Rule 18 holds throughout: the guest's patched instructions still execute as written on the dirty-RAM interpreter. Only the code around them changes backend. Nothing is synthesised. Tests: runtime/tests/test_kernel_patch_ranges.c (new, the verifier's accept/reject behaviour and the hand-back predicate) and the install-slot range invariants in recompiler/tests/bios_address_model_test.cpp. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-11 16:38:34 -04:00
Matthew Stanley	5b3c7dd08d	phase4: freeze_check diagnostic + accumulated overnight infra ... Today's session work - runtime/src/debug_server.c: freeze_check TCP cmd snapshots all liveness counters (PC, exception entries, exception_reentry_blocks, dirty_ram blocks/insns, fn_entry total + top-K histogram, SIO IRQ pending + countdown, sio_stat/i_stat/i_mask, mc_max_state) for tight-loop diagnosis when the runtime hangs - runtime/src/debug_server.c: wtrace slot 12 covering [0x72F0..0x72F4] (data-byte counter); measured peak=1 confirming setup_data_phase resets the counter mid-cycle - runtime/src/interrupts.c: exception_entries_total + exception_reentry_blocks counters + psx_get_freeze_diag accessor - runtime/src/sio.c: sio_get_freeze_diag accessor for IRQ pacing internals - memory entries: phase4_card_gate_setup_writes_2026_04_28 (refutes the prior \"missing [0x7568+slot] clearer\" framing — setup functions write LSB=0 directly), phase4_72f0_one_byte_per_vblank_2026_04_28 (peak=1 measurement) Overnight session work bundled in - runtime/src/dirty_ram_interp.{c,h}: small MIPS interpreter for install-at-runtime kernel RAM stubs (Rule 18; e.g., SIO data-byte handler the BIOS writes to RAM 0xCF0) - recompiler/src/full_function_emitter.{cpp,h}: 3057 jal/jalr continuation return labels added to dispatch table (continuation fix); branch fall-through fix for conditional-branch delay slots - recompiler/src/strict_translator.cpp: matching translator updates - generated/: regenerated SCPH1001 dispatch + full C output reflecting the recompiler changes - runtime/include/debug_server.h, src/memory.c: card_txn ring + SIO IRQ ring + EvCB walk ring + per-PC dirty_ram counters + always-on wtrace coverage for [0x755A], [0x7514], [0x7528], [0x7520], [0x74A4], [0x75C0..C8], [0x74B8..C0] - recompiler/tests/, runtime/tests/: SIO/card protocol unit tests - tools/: 60+ Python diagnostic scripts (chain_trace analysis, SIO trace diff, EvCB walker, wtrace dumpers, etc.) - docs/: psx_bios_disasm reference + dynamic_handler_install rationale - OVERNIGHT_2026_04_28.md, SUMMARY_20260412_2.md: session logs Phase 4 status (still blocked, root cause better understood) - BIOS card chain runs through R-handlers correctly (chain_trace shows R1..R11 cycling 26x); shell IS retriggering _card_read - Install handler at ROM 0xBFC15F1C increments [0x72F0] correctly per SIO IRQ; gate at <0x80 / <0x7F is correct - Bottleneck: SIO IRQ countdown is access-paced, fires ~1× per VBlank vs ~128× needed; setup_data_phase (called from outer coord on VBlank) zeroes [0x72F0] before counter reaches 128 - Both attempted fixes today caused freezes: * VBlank deferral on [0x75C0]==1 — pending VBlank already in i_stat delivered anyway; tighter dispatch gate also locked up * Cycle-paced sio_tick at rates 50, 200 (and gated on [0x75C0]==1) — runtime freezes once data phase activates, root cause unidentified - delay=5 narrows the threshold (peak=2 vs peak=1, no freeze) but doesn't get to 0x80 - Real fix likely requires deeper instrumentation of the freeze (call stack / dispatch state at the moment of TCP starvation) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-28 21:29:19 -07:00