mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-25 18:05:12 -04:00
Matthew Stanley
a9ab4d914d
Codegen audit (tools/_codegen_audit.py) revealed two related dispatch-miss
classes after the predicate-init fix.
(1) Discovery missed the A0/B0/C0 syscall trampolines at BFC428D0-BFC42C00.
These are 8-16 byte stubs of the form
li t2, 0xa0/b0/c0
jr t2
_li t1, FUN_ID
that wrap kernel syscall dispatch. Ghidra had no xrefs to them (callers
reach them via patterns auto-analysis didn't trace), so they never made
it into ghidra_function_starts.json and from there into seeds. The
recompiler decoded JALs targeting them (visible as `psx_dispatch(cpu,
0xB005A8F0u)` etc. in regen output) but with no dispatch table entry,
these calls hit psx_unknown_dispatch and silently no-op'd.
For the YES/NO confirm modal, this likely manifested as the modal's
CROSS handler calling e.g. TestEvent (B0:0xB at BFC42A00) and getting
no result, leaving the modal in indeterminate state.
Added 50 explicit seeds for BFC428D0..BFC42C00 (trampolines) plus four
small kernel/libgte stubs (BFC304AC, BFC30584, BFC33C90, BFC33D1C —
`jr ra; _li v0, X` return-constant helpers) which were also dispatch
misses via tail-call paths.
(2) full_function_emitter.cpp's relocate_j_target/relocate_ra clamped the
shell relocation range at phys 0x1FC427FF, but the runtime dispatcher's
normalize() (SCPH1001_dispatch.c) handles shell up to phys 0x1FC42FFF.
This left JALs in BFC42800-BFC42FFF un-relocated — the JAL target kept
ROM PC[31:28]=0xB instead of being remapped to RAM PC[31:28]=0x8.
Concrete example: `jal 0xB005A910` at BFC4282C, where the intended
runtime target 0x8005A910 (a trampoline at RAM offset 0x2A910 = ROM
BFC42910) became 0xB005A910 (KSEG1 mirror of RAM 0x005A910 — random
address far outside any dispatch-table entry).
Extended bound to 0x1FC42FFF in both lambdas to match the runtime.
Audit results: direct dispatch misses 47 -> 0, tail-call misses 5 -> 1.
Remaining 1 is RAM 0x00000CF0 (dynamic install stub, handled by
dirty_ram_dispatch per Rule 18).
Awaiting user repro to confirm YES/NO modal action handlers now fire.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>