Files
BFM-decomp/tools
Drew T 10dc6d3635 feat(phase-30 S1): --span-rel unblocks the zero-crack head; func_8014032C ×1 probe banks (§132b)
S1's head family (0x8014032C, 183 ins ×137 = 25,071 templatable ins) gate-failed on its probe
sibling. Diagnosis (the §132 ladder, one build): the object emits FOUR tables — BOTH functions in
it are multi-switch (8+5 entries each) — while the carve derived THREE starts.

The missing start belongs to the ALREADY-MATCHED owner func_8013FFD8, and neither oracle can see
it: its stub .s is pruned by extract, and its second table abuts its first with NO pad (8 entries
= 32 B = 0 mod 8, so `.align 3` emits nothing) — precisely the honest limit §132's payload
zero-word recovery documents. Note the true pads [0,0,4,0] are exactly what natural alignment
produces; the build breaks only because a SHORT spec gets written.

Fix: thread the documented `--span-tables` escape through the sweep as `--span-rel` — offsets
relative to the FIRST NEW table, which func_jtbls reads from the sibling's own .s. Byte-verified
family-invariant before use (identical relative offsets on 3 sampled siblings; same code, same
entry counts, only the base moves). Empty by default => every other family untouched.

Also clears my own §132a guard of suspicion (R14): the --like transfer was inert here regardless
(exemplar subseg `ov_SC01_077` vs sibling `_jr_8013FFD8` — roles never matched).
2026-08-01 08:26:30 -06:00
..