Commit Graph

2 Commits

Author SHA1 Message Date
Drew T 9351b17f48 feat(phase-30 S46-2): the master IDXTAB/DESTPTR load map — and the tracker blind spot that hid it
Drew's S45 idea, delivered fleet-wide + wired into the permanent references.

- THE BLOCKER WAS OUR INSTRUMENT (R35, the 3rd time): the S45 plan ("require a
  register-verified reference to the run's address") returns ZERO for both byte-proved
  tables. They are read by gcc's indexed global-array form —
      lui $at,0x8019 ; addu $at,$at,$a0 ; lh $v0,-0x2844($at)  -> 0x8018D7BC
  — where the address exists only as (lui imm, LOAD offset) with the index add between.
  find_addr_refs killed the lui register at the addu, so the halves never rejoined and
  the tables looked unreachable. Now it carries the hi half through the index add (still
  strictly register-tracked, never window-paired) and labels those hits `-indexed`.
- tools/idxtab_map.py (NEW): fleet-wide payload -> owning binary -> load address.
  Controls-gated (refuses to emit unless ov_SC01_000 0x8017EEC8/37 + *0x801A3234, and
  ov_SC03_001 0x8018D7BC/5 + *0x801EBC68 reproduce from the images alone). Index space
  DERIVED from the extracted tree (reproduces §S44's table independently). Process-pooled.
  Rejects all-zero and majority-zero runs (132 of the first pass's 452 "tables" were that).
- RESULT: 213 binaries -> 143 with a referenced table (294), 141 with a DESTPTR (141/141
  resolved from the binary's OWN image), 61 payloads. The two dominant tables are
  fleet-wide CONSTANTS (5-entry and 37-entry, identical in all 141 overlays); the
  per-binary variable is the destination (134 distinct).
- CORRECTION 1 (R14): §S45 p6's "the SC03 trio are owned by ov_SC03_001" is refuted —
  that 5-entry table is identical in ALL 141 overlays. The byte-observed parts stand.
- CORRECTION 2 (P9): this route CANNOT settle MAIN/7+9. They are absent from all 294
  tables — but so are MAIN/13/20/34/42/44, which are byte-proved to load. Absence here
  means "not on this route", nothing more. Recorded so it is not re-derived as a finding.
- Confidence is stated per-claim in docs/idxtab-map.md: proven (controls) / high (283
  fleet-wide-class tables) / low (3 named rare rows) / UNMEASURED (recall — no oracle
  for "all tables" exists beyond the 2 controls).
- Wired in permanently: docs/idxtab-map.md (the how/when/limits), memory-map.md §S46,
  cookbook §155c (the generalizable law: "no code references X" is a claim about your
  DECODER until it is shown to recognise the forms the compiler emits), SETUP.md
  tooling inventory (R21).
2026-08-07 22:09:05 -06:00
Drew T 537bd90a9a feat(phase-30 S45p6): SOLVED — the SC03 trio are ov_SC03_001's script modules (static decode)
Found the IDXTAB: ov_SC03_001 @0x8018D7BC holds 5 s16 entries, -1 terminated:
224, 231, 232, 234, 233 — i.e. the ENTIRE parked trio (SC03/53/54/56) plus its DATA
companion (SC03/55 = 233), in one table, in the binary whose *DESTPTR points at the
script-module slot the tracer watched load live an hour earlier.

THE CHAIN (every link register-verified or byte-observed):
  ov_SC03_001 IDXTAB @0x8018D7BC  -> indices 231/232/234 (+233 data, +224)
  func_80128CFC (the S44 wrapper) -> cdFileLocTable[idx] -> {loc,size}
      register-tracked: addiu->0x800AE830, lw[0x800AE834] size, lw[0x800AE830] loc
  *DESTPTR @0x801EBC68 = 0x801EF468 -> the script slot
      the ONLY occurrence of that word fleet-wide; read 8x by code, 2x from inside func_80128CFC
  slot confirmed LIVE by tools/cdtrace.py: SC03/76 and SC03/34 both loaded there
  and 0x801EF468 lies inside SC03/54's independently-derived base window [0x801EDED0..0x801EF6C8]

VERDICT: LIVE script modules owned by ov_SC03_001. Not dead code, not boss-gated, not
chapter-gated (that framing retired — scripts swap per SCENE). Every sweep missed them
because the SC03 scenes we visited run DIFFERENT overlays (124/125/051).

WHY THE EARLIER HUNTS COULD NOT WORK: the index never appears in CODE — it lives in a
per-overlay DATA table, and so does the destination. Both invisible to fleet-wide code
scans. That is the structural reason four value-scans and three payload-side oracles failed.

NOT PROVED: the exact load BASE within the slot (the three differ in size; none observed
loading). The byte-gate arbitrates — onboard at 0x801EF468 and let the first build decide.

New tool: tools/find_addr_refs.py — register-tracked absolute-address search (cookbook 155:
no window-pairing), self-tested against cdFileLocTable, with a STRICT addu-index rule
(full-address match, not page match — 342 loose hits -> 7 real ones).

METHOD: a runtime observation supplied ONE constant, and that made a previously-impossible
static decode trivial. Neither alone sufficed. Pair the oracles, don't choose between them.
2026-08-07 20:41:18 -06:00