mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-28 06:49:47 -04:00
85fb289db582d842fc41dc059fa187bb992e76ea
15 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Drew T
|
ec1f388d16 |
fix(phase-30 S48): name the §154-A leading-island wall instead of mis-blaming the carve
`jtbl_family_bank` fed every module jr member to `jtbl_carve`, which died with
`jtbl_… not found in the raw data asm`; `harvest_verify` turned that into
CARVE-REFUSED and never built. So the verdict named the TOOL, and 12 slots in
the wave-1 propagation read as a carve bug. Probing one member to the byte
level shows it is a LAYOUT the carve model does not cover:
A module binds `.rodata` at 0x0 to the SAME subseg as its code (§154-A), so
the object's rodata order IS the C file's include chain — INCLUDE_RODATA
pieces, then each INCLUDE_ASM'd function's MIGRATED table, in address order.
That reproduces the island exactly while the function is a stub. Matching it
PRUNES its .s, its table leaves the chain, and cc1 re-emits it at the END of
the object's .rodata: build 43,768 vs 43,760 bytes, first diff at 0x144
inside the island's own pointer table.
`JTBL_PADS` does not reach it either — `jtbl_rodata_pads` refuses the object
outright ("unexpected rodata content .include ... D_801EF468.s"): the carve
model covers jump tables, not an island of mixed included data.
- `migrated_tables()` detects the layout by EVIDENCE (table absent from the
data asm, present as a dlabel in the function's own .s), refuses loud with
the measurement and the design that would work (isolate the jr function into
its own subseg so its .rodata is a separate OBJECT, then ld_interleave — the
§8 machinery re-aimed at a LEADING island instead of a data tail), and
refuses a mixed carve set rather than half-carving (R32).
- Regression-checked both ways: overlay stubs classify [], modules classify
migrated.
SIZED (R37): 70 module binaries, 42 with this layout; 1,345 open module
member-slots in sibling families, of which only 44 are jr. The island work is
worth 44 slots — it is NOT the module lane's main gate.
R22 clean-fleet: 213 passed / 0 failed of 213.
|
||
|
Drew T
|
ec749fa584 |
fix(phase-30 S48-0b): JTBL_PADS follows its span through jr isolation
The 0b blocker was not "the pads line is left behind" alone — it fails two different ways, and the second one is silent: * bare isolate + `make build`: the stale line arms the pads filter on the RESIDUAL object, which emits no jump table -> `jtbl_rodata_pads: consumed 0 rodata .align(s) but 4 pad spec(s) given` (S47). * isolate -> jtbl_carve (the jtbl_family_bank path): `set_pads_vars` regenerates the block keyed by the CURRENT subseg names, finds no prior spec under the new `_jr_<addr>` name, and DROPS the line. cc1's natural `.align 3` then pads the span's non-8-aligned interior tables and the image shifts — reported only as `built, bytes differ`. - jr_isolate_all.repoint_overlays_mk: repoint the `build/src/<ov>/<sub>.o: JTBL_PADS` target with the `--order` leaf whenever a carve moves; refuse loud if the old object still hosts a .rodata piece (R32). - jtbl_carve.set_pads_vars: second, disagreeing oracle (R34) — refuse when a spec would vanish for a subseg no longer in the carve set (rename/merge drift), instead of silently emitting a padless object. R37 probe: func_801789AC -> ov_SC02_037 went `built, bytes differ` -> BANKED on the whole-binary byte gate. ov_SC02_037's spec is 0,0,0,0 over tables +0x0,+0x14,+0x34,+0x4c — load-bearing (span start is 4 mod 8). |
||
|
Drew T
|
b9efe66f91 |
fix(phase-30): the JR-PAIR "wall" was TWO instrument defects — pair banked, class retired
S28 ledgered `JR-PAIR-IN-ONE-O0-OBJECT` (two jr fns matched in one -O0 object => a clean build that cannot link: `undefined reference to $L105` + `func_8013C938`) with §81 step 1 (isolate one into its own code subseg) as the untested escape. BOTH the class and the escape are REFUTED — no isolation, no compiler wall, both fns banked from a genuinely clean fleet. The 4th consecutive "structural wall" to resolve to our own tooling (§124/§125/§126/§131). - DEFECT 1 (tools/jtbl_carve.py): ov_SC01_077_o0's carve at 0xb01a4 predates the §8e `tables=` persistence and is a MERGED DOUBLE (func_8013C0F8 $L75 + func_8013C414 $L105); the 2nd owner is MATCHED so extract pruned the stub .s naming its table. The single-table- predecessor inference derived 3 starts where the object emits 4 tables -> JTBL_PADS 0,4,4 -> jtbl_rodata_pads refused mid-stream, correctly. FIX: R32 coverage assertion + payload recovery at the single choke point (spec_from_starts) — every zero word inside a span is an original `.align 3` pad (the tool's own axiom), so the word after it STARTS a table; recovered starts are logged. No-op where structure is known (the 134 sibling _o0c spans carry tables=+0x0,+0x70). Honest limit: tight (0-pad) boundaries stay unrecoverable but fail LOUD via the filter's count guard — never silent. - DEFECT 2 (Makefile): no .DELETE_ON_ERROR, so `as` (a pipeline consumer) left a TRUNCATED .o on disk — 12 of 16 T func_, undefined $L57/$L59/$L63/$L75/$L76 — newer than its .c, and the NEXT build linked the corpse. That IS the S28 link error, one build downstream of a loud, correct compile error. Negative-control-proven on a scratch invocation. - BANKED: func_8013B83C (272 ins) + func_8013BD74 (198 ins) in ov_SC01_077 (d19c9580). Byte proof: 4 tables 0x801D8254/828C/82FC/836C (13/27/27/27 entries, each zero-pad separated); span 0xb00fc..0xb0280 = 388 B = 52+4+108+4+108+4+108 exactly; spec 0,4,4,4. - R22 clean-fleet (make clean + extract-all + check-all): 140 passed, 0 failed of 140. The incremental result was NOT trusted (§130). Fleet 93.25% fn-count / 89.2% instr / 80.5% distinct; dedup 1905/0; 0 NON_MATCHING (G4). - cookbook §132 + index (356 sections): the mechanism, the fingerprint (an undefined $L<n> in a LINK error is a truncated object, never codegen), the 30-second standalone-TU ladder that named the 4th table owner before any build, and the transferable rule — a fail-loud guard is only as trustworthy as the artifact hygiene around it. |
||
|
Drew T
|
0958120006 |
fix(phase-30): jtbl_carve OVER-SPAN clamp — the one real instrument failure, root-caused and fixed; behemoth func_80191C50 (710 ins) banked
The last surviving "compiler wall" of the session turned out to be an off-by-one-word
carve. Chain, all byte-grounded:
SYMPTOM jtbl_carve diverges on ov_SC06_018 after a BYTE-NEUTRAL jr_isolate_all.
SHAPE image -3 bytes; 853 differing bytes in 699 scattered runs; **812 at byte 0 of a
word** = the low byte of a 16-bit immediate, every sampled one changing by
exactly -4. Not a shift, not a pad: hundreds of `%lo` operands 4 bytes low.
CAUSE func_80191C50's own `sltiu $v0,$v1,0xC` names 12 entries; the emitted .rodata
holds 12 words; the carve reserved 13. The 13th word (0x3038200A) is ordinary
NON-ZERO data that spimdisasm ran into the dlabel span (the next dlabel sits
past it). Reserve 13 / supply 12 => the .rodata piece UNDER-FILLS by one word
=> every later symbol slides down 4 bytes.
WHY MISSED The trailing-trim's axiom is "0x00000000 cannot be a jump target", so it only
trims ZERO words. This surplus is non-zero, so nothing trimmed. The tool already
treats `sltiu` as ground truth - it EXTENDS a table spimdisasm cut in half, and
it WARNS when a span is too short - but had no clamp for a span too LONG.
FIX: an over-span clamp with the SAME authorization as the existing extension logic -
only when the `sltiu` bound is UNAMBIGUOUS (one bound; a multi-switch fn cannot say which
table owns which), and only when the surplus words are NOT plausible code addresses. If any
surplus word looks like a real entry it REFUSES LOUDLY rather than silently dropping one.
jtbl_carve: jtbl_801D3BA4: clamped 1 trailing NON-ZERO word(s) - func_80191C50's own
`sltiu 12` names 12 entries and the surplus is not code
Then: carve BYTE-IDENTICAL, draft spliced, **func_80191C50 (710 ins) BANKED**.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
Retires the JTBL-CARVE-BREAKS-BYTES ledger class: the one instrument failure that survived
this morning's retraction round was REAL, and is now a named bug with a fix - not a wall.
|
||
|
Drew T
|
a5e5ea45ef |
fix(phase-29): jtbl_carve — guard the --like role-transfer; the ×137 sweep goes 0/3 -> 3/3
ROOT CAUSE of the 0/3 (found by reading the tool's ACTUAL invocation, not by guessing): jtbl_family_bank calls `jtbl_carve <sibling> --func <fn> --like <exemplar_ov>`, and the role-transfer keys on the SUBSEG ROLE (`ov_SC01_077_a` -> `_a`). Its premise — "same family => same span structure" — silently breaks when the exemplar and the sibling host the function in subsegs with DIFFERENT roles, which happens whenever the exemplar has a split the sibling does not. MEASURED: func_8012AAAC lives in `ov_SC01_077_a` (role `_a`) in the exemplar but in the MAIN subseg (role ``) in every sibling. The transfer therefore looked up `ov_SC01_077` — an unrelated SEVEN-table span belonging to entirely different functions — and stamped those starts onto a sibling span holding one table. jtbl_rodata_pads then refused with `consumed 1 rodata .align(s) but 2 pad spec(s) given — table-count drift`, and jtbl_family_bank deliberately does NOT treat that error as isolate-fixable, so all 137 siblings returned a bare `gate-fail` with the cause discarded. THE FIX: transfer only when the exemplar's subseg for THIS FUNCTION has the sibling's role; otherwise derive the span from the sibling's own carve (which was already computing it correctly). Fail-open is not acceptable here — a wrong table set corrupts the image, so the guard defaults to local derivation. MEASURED RESULT: the 3-member probe goes 0/3 -> 3/3 BANKED. R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed. Two earlier hypotheses were tested and are recorded honestly in CURRENT_PHASE.md: the sibling call-site casts (real conflict, fixed, byte-neutral — but NOT the blocker) and my own carve-alone test (which fails by construction for this shape, because a stub object does not emit the table its 2-entry spec describes — the tool splices the body BEFORE building, so its path is the valid one). |
||
|
Drew T
|
2cc49d0310 |
feat(phase-29): SESSION-21 — func_8012AAAC banked via the §81 carve chain (R22 140/140)
The first jtbl-routed bank of the session, and it validates the whole chain end-to-end:
1. jtbl_carve SPLIT-TABLE repair (this session): jtbl_801D7FB0 28 -> 50 words (112 -> 200 B),
authorized by func_8012AAAC's own `sltiu 0x32`.
2. NEW FIX — SINGLE-TABLE PREDECESSOR: adding a second table to a subseg whose existing carve was
single-table lost the FIRST table's start entirely (new_offs has only the new one;
overlay_jtbl_addrs cannot see the old one because its owner is banked and extract PRUNED the
stub .s; and single-table carves persist no tables= to rebase). The span then failed its own
validator with "first must equal the span start" — the invariant naming the missing entry.
A single-table carve spans exactly its one table, so ITS SPAN START *IS* THAT TABLE'S START:
inference, not persistence, so it also works for spans carved before tables= existed. This is
the RECOVERABLE half of the documented func_8013F350 lesson (that one was a pre-§8e merged
DOUBLE — two tables, no record, genuinely unrecoverable).
Result: ov_SC01_077_a JTBL_PADS := 0,0 tables=+0x0,+0x14. Carve alone byte-gated BYTE-IDENTICAL
BEFORE the bank was attempted (§81 step 2).
3. ARITY axis, all-or-nothing: 1,244 decl sites / 1,240 files `(void)` -> `()` + an R32 completion
assertion (old-form remaining: 0).
4. ONE call-site cast: the definition lands at line 811 and a 0-arg call sits at 822, so gcc sees
the prototype and rejects it — `((void (*)(void))func_8012AAAC)()` (§17a-1; gcc folds the cast
of a known symbol to a direct jal). Only 1 of the 1,386 fleet-wide 0-arg call sites needed it:
the others see only the `extern ()` decl, which permits a 0-arg call.
DIAGNOSIS NOTE: the failure read CC1-FAIL with only a warning visible under make. Running the
pipeline stage-by-stage (cpp | cc1 | maspsx | jtbl_rodata_pads | as) put it on cc1 rc=33, and cc1's
own stderr named it exactly: "too few arguments to function func_8012AAAC" at line 994. Isolating
the stage was what turned an opaque Error 33 into a one-line fix.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
family_sweep correctly REFUSED this exemplar (§53: a jr-family must route through
jtbl_family_bank.py; "a 0% from this path would be a TOOL artifact, not a wall") — the ×137 member
sweep is the next step and needs a clean tree, which this commit provides.
|
||
|
Drew T
|
87b02b044f |
fix(phase-29): jtbl_carve — repair the SPLIT-TABLE undercount, gated on the function's own sltiu
THE BUG (real, found by a wave agent): jtbl_range() ends a carve at the next data dlabel, assuming every dlabel is an object boundary. spimdisasm can CUT ONE JUMP TABLE IN HALF and emit the tail under an invented D_ label — func_8012AAAC's 50-word table is jtbl_801D7FB0 (28) + D_801D8020 (22). The carve then reserves 112 B for an object supplying 200 B of .rodata, shifting every later symbol. §84-class: match_one is structurally blind; it surfaces only as a whole-binary DIFF. THE AGENT'S EVIDENCE WAS WRONG (R14): it reported D_801D8020 as having "ZERO xrefs anywhere in the tree" and proposed deleting the label. It has TWO (.word D_801D8020 and +0x2 in tail.data.s) — almost certainly spimdisasm mis-symbolizing packed halfword data, but "almost certainly" is not a gate, and the proposed remedy would have deleted a symbol two emitted words reference. I built the xref census first, watched it refuse, and only then found the references. THE GATE USED INSTEAD — the function's own `sltiu N` range check, which gcc emits right before the indexed load, so the PROGRAM declares its own table length (func_8012AAAC: sltiu 0x32 = 50). Absorb only when the next label is immediately adjacent, its words are all code addresses in the overlay's text, and absorbing lands on an EXACT sltiu bound (the SET, not max() — a multi-switch function has several and no way to say which owns this table). Three further corrections, each caught by testing rather than assumed: - the absorption fired and the trailing-pad trim immediately UNDID it (re-trimming against the first dlabel's 28 words); the trim now sees the whole absorbed table; - a continuation ends at ITS OWN last .word, not the next dlabel (D_801D8020 ends 0x801D8078; the next dlabel is 0x801D8158, 224 B on) — using the next dlabel is the assumption being repaired; - the shortfall warning now fires only on an unambiguous single-bound pairing (it fired ~90 times across 38 tables before the guard — a warning that fires on ambiguity is noise, not a signal). VERIFIED: the split table 28 -> 50 words (112 -> 200 B), matching the agent's 3 independent confirmations; and across 38 jtbls x 6 functions = 228 combinations, EXACTLY ONE range changes — that table, for its owning function only. |
||
|
Drew T
|
1cb018bc00 |
feat(phase-29 §8e): bank giant func_8013F350 (490) x1 — the 4-table [0,0,4,0] span + tables= persistence
- jtbl_carve §8e hardening (the F350 lesson): a pre-§8e Phase-26 merged-double span had NO
recoverable structure — spec derivation now uses the payload ZERO-WORD rule over persisted
table starts (tables= comment on the JTBL_PADS line), with source priority
{untouched+line=reuse verbatim | untouched+no-line=skip | touched=union of .s refs,
line tables=, --span-tables override, --like exemplar role-transfer}; spec_from_starts
replaces interval-carry; None-tolerant legacy comments; --like/--span-tables CLI.
- F350 carve: tables 8860(8e)+8880(5e,trimmed) fused BEFORE the existing 8898/88B8 double via
the zero-checked 4-gap -> ov_SC01_077.o JTBL_PADS := 0,0,4,0 (tables= persisted).
- splice reconciles (§56, byte-neutral): §30#2 def-side widen void->s32 (TU extern +
engine_core discarding-caller macro extern); D_80115158/D_8011515C macro-canonical redecls
+ §18 width-preserving store casts (sh under u8[]/u8); func_801416D4 canonical (s16) redecl
+ §17a-1 fn-ptr (s32) call cast; D_80187BD0 block-scalar decl dropped (file array covers).
- whole-binary gate [ OK ] sha1 d19c9580 == check. 3 of 4 giants now banked x1.
|
||
|
Drew T
|
db2daf47e4 |
feat(phase-29 §8e): bank giant func_80159C84 (337) x1 — isolate + the FIRST pad=4 spec
- NON-CONTIGUOUS -> jr_isolate_all --only (new jr_80159C84 subseg, 2 region files); jtbl_carve func_jtbls: stale-location .s CONTENT fallback (ownership stays config-derived) — needed once a spliced fn is re-extracted (no fresh .s anywhere). - carve: jtbl_801D8AFC (7e, trimmed) + pad word + jtbl_801D8B1C (5e, trimmed) -> JTBL_PADS := 0,4 — the first reproduced ORIGINAL interior pad (the §8a 'handle then' address). - splice reconciles (§8d carried-layer-wins, all byte-neutral): draft scalar typedefs stripped; 3 draft decls dropped for carried (D_801891B8 void*, D_8018911C u8 addr-only, func_80149FB0 s32); 3 call-site casts + the §17a-1 fn-ptr cast for canonical-(void) func_80161208. - whole-binary gate [ OK ] sha1 d19c9580 == check. |
||
|
Drew T
|
5e78dccf07 |
feat(phase-29 §8e): jtbl 8-align pad-spec filter — the 4-giant unblock tooling (fleet-neutral)
- ROOT CAUSE PINNED (the session-2 half-pin was INVERTED; both probes were vacuous, R35): cc1 emits .align 3 before EVERY jump table; maspsx passes it VERBATIM (the :435 'drop' is an inventory-only pass); as bakes the pad SECTION-RELATIVE; link placement was never guilty (SUBALIGN(2) + ALIGN(.,4) place 4-mod-8 carve starts tight). Merging originally-separate TUs fires an intra-TU align where the original packed tight -> +4 at rodata 0xCC -> image-wide %lo shift. Honest probes persisted: .run/probe_jtbl/ (verdict.md + objdumps). - NEW tools/jtbl_rodata_pads.py: post-maspsx filter replaces each rodata .align 3 with the ORIGINAL's exact pad bytes per a JTBL_PADS spec; fail-loud on table-count drift / non-align-3 / non-jtbl rodata content. Byte-proven: verbatim 0xE4 pad-at-0xCC -> filtered 0xE0 tight (= the merged carve span). - jtbl_carve.py: spec-aware same-subseg merge (gap 0 or 4-with-zero-payload-word; else NON-CONTIGUOUS -> isolate), interval-arithmetic pad specs (committed values CARRIED, never re-derived), JTBL_PADS target-var emission into overlays.mk + revert() restore + stale-.o invalidation; the false 'maspsx drops .align' docstring corrected (H5). - Makefile: $(if $(JTBL_PADS),| jtbl_rodata_pads.py ...) stage in build/src/%.o + file-scope empty default (env-shield). jtbl_family_bank.stub_file: duplicate-stub fail-loud (the earlier 'ladder failure' was a wrong-TU splice into a stale _a.c stub, byte-witnessed). - R22 clean-fleet WITH the fix wired: 140/140 byte-identical, tools-health green (dedup 1846/0, C1 234205/234205), ZERO new banks -- fleet-neutral by construction. - cookbook §8e (the jtbl alignment law) + §8a/§8a-pad corrections; decision-log R31 entry; SETUP.md tool row; .gitignore allowlist for the probe verdict artifacts. |
||
|
Drew T
|
b0691f4bd9 |
fix(phase-26): jtbl_carve trims trailing .align pad words (§8a-pad)
A trailing `.word 0x00000000` under a jtbl dlabel is the ORIGINAL TU's intra-rdata .align 3 padding, NOT a table entry (0x00000000 is not a jump target). The true entry count is the fn's `sltiu <n>` bound: func_8015AE2C has sltiu 0x7 = 7 entries yet its raw dlabel spans 8 words. maspsx drops all .align, so a C-emitted jump table can never reproduce the pad. Carving to the next dlabel would reserve 8 words while the compiled object supplies 7 -> .rodata under-fills by 4 B -> every later symbol shifts +4 (the same image-corruption class as §41d). jtbl_range now trims trailing zero words, leaving the pad in the raw post-carve data piece. Retroactively explains the §8a func_80159C84 '5 words vs the real 6' false-MATCH. Existing carves are parsed from CONFIG, not re-derived, so committed banks are unaffected (verified: the 3 carved jtbls are absent from the raw data asm). The build never invokes jtbl_carve, so the fleet is inert to this change until the next bank. Found by the Fable5 crack of func_8015AE2C (562 ins x134, MATCH, pin-free). |
||
|
Drew T
|
38ac5659aa |
feat(phase-26): §8b scoping wall BROKEN — decl-environment reconstruction + lazy per-core isolation
The full 54-jr isolate-all on ov_SC01_077 now builds d19c9580 BYTE-IDENTICAL
(R22 clean-fleet 136/136) — the configuration session 5 could not build. The
heavy-jr harvest (191 cores / 5.53M templatable ins) is unblocked.
- R14 CORRECTION: session-5's "gcc-2.7.2 block-scope-extern TU-persistence" root
cause was WRONG. There is no gcc quirk — DEFINE_func_* macros expand at FILE
scope, so their leading externs are genuine file-scope decls that merely live in
engine_core.h, invisible to any col-0 .c scan (1377 macros / 3929 lines / 1462 syms).
- REJECTED the approved "global symbol->type map + shadow set" design: the engine is
loosely typed (func_80173544 is DEFINED `s32 f(void*)` yet declared `extern void
f(void);` inside func_801734BC's body), so declaring every USED symbol hoists that
block-scope shadow to file scope and CREATES the conflict a shadow-set then dodges.
Instead reconstruct the original TU's file-scope decl environment and carry it
strictly FORWARD — conflict-free by construction (every carried decl already
coexisted with every definition in the one original TU; compatibility is
order-symmetric; shadows stay in bodies and travel with their item).
- The byte-gate found two MORE lost decl sources, not predicted: (a) a definition is
itself a declaration for everything below it in its TU (func_8012B2CC undeclared);
(b) file-local typedefs used by a carried prototype (parse error, Vec3s). K&R defs
must render `extern T f();` (unprototyped), never f(void).
- LAZY per-core isolation wired into jtbl_family_bank (Drew's call — upfront-x134 =
~7,200 region files): jtbl_carve NON-CONTIGUOUS fail-loud -> jr_isolate_all --only
<core> -> re-extract -> re-carve. Proven on func_80178D40 (890x134, heaviest core):
carve blocked -> isolated (byte-neutral d19c9580) -> carve in its own subseg.
- TWO LATENT BUGS fixed (both would have corrupted the heavy sweeps):
* jtbl_carve.func_subseg derived the owning subseg from the ASM TREE, which `make
extract` never prunes -> after an isolation it returned the STALE owner and
silently re-created the very collision the isolation removed. Now config-derived.
* jtbl_family_bank/jtbl_carve revert() DELETED the shared overlays.mk carve var
unconditionally -> would destroy a COMMITTED carve (all 134 overlays have one) on
any failed sibling. Now restored to its committed value; only region files created
by this attempt are removed; dirty-tree preflight refuses to start a sweep.
- docs: cookbook §8b RESOLVED + new §8c "splitting a TU means rebuilding its
DECLARATION ENVIRONMENT, not moving text"; decision-log 2026-07-13 (R30/R31).
- parser selftest 404/404; R22 clean-fleet 136/136; 0 NON_MATCHING (G4).
|
||
|
Drew T
|
d1dd29d815 |
feat(phase-26): §8b multi-jtbl same-subseg — contiguous MERGE (built) + isolation scaffold
Session-4 same-subseg handling (the de-risk preamble's harder half; byte-proof of the merged build + isolation deferred to Stage 2 with concrete cores): - jtbl_carve.py: MERGE adjacent same-subseg carves into one spanning .rodata piece (a code object emits its jtbls contiguous, so two matched jr-fns in one subseg are byte-correct iff their jtbls abut). BOUND-FIX: a new jtbl's end is bounded by the next raw dlabel OR the next existing carve start (an already-carved adjacent jtbl is gone from the data asm -> raw dlabels over-extend it -> false "non-contiguous"). Config-proven (func_80171B4C 801D8C48 merges with func_801734BC 801D8C68). NO-OP for family-1/cross-subseg (single carve per subseg) -> committed configs unaffected. - jr_isolate.py (scaffold, NOT yet functional): the non-contiguous case — split a fn into its own code subseg (whale _o0b precedent) so its jtbl carves independently. BLOCKED on split_src_region, which can't partition the overlay .c (global canonical- sig extern layer + per-fn callee-externs + DEFINE_func macros + @class annotations, ~922 non-address items). Stage-2 build item (overlay-.c-aware source split). - cookbook §8b (the --order sandwich + the two same-subseg cases + the blocker); CURRENT_PHASE session-4 checkpoint updated with the Stage-2 unblock decision. |
||
|
Drew T
|
ca50ee6978 |
feat(phase-26): §8 multi-jtbl --order carve + family-1 (func_801734BC ×134)
- ld_interleave.py --order: address-ordered N-piece data->rodata->data sandwich for overlays with 2+ matched jr-functions; legacy --front/--tail path is byte- untouched (main EXE + the 133 single-carve func_8012ACE0 siblings unaffected) - jtbl_carve.py rewritten additive/regenerate-from-config: parse the tail data region + existing .rodata carves, split the containing data piece for the new jtbl, re-emit the address-ordered pieces + the --order arg; same-subseg carve collision fails loud (-> jr isolation); idempotent - jtbl_family_bank.py: `make extract` BEFORE the carve (asm must match the reverted committed config; the old error-string retry was fragile) + revert-on-carve-fail - family-1: func_801734BC (34-ins PURE jr, ov_SC01_077_after) matched in ov077 (shared-tail switch idiom) + banked 133/133 siblings = x134 — CROSS-subseg multi-jtbl (func_8012ACE0 in _a + func_801734BC in _after) - R22 clean-fleet 136/136 byte-identical (~52s); 0 NON_MATCHING (G4) |
||
|
Drew T
|
5a08180617 |
feat(phase-26): §8 ×134 automation — func_8012ACE0 banked fleet-wide (133/133, R22 136/136)
- the jr-function ×134 harvest pipeline, proven end-to-end: per family sibling,
jtbl_carve (per-sibling jtbl-rodata carve, computed from THAT sibling's own jtbl
address — the fn is at the same vram across overlays but its jtbl floats) -> make
extract (auto ld_interleave) -> remap_hseq + canon_sig_reconcile -> whole-binary gate
- tools/jtbl_carve.py: per-overlay §8 carve generator (config data-tail split +
<ov>_JTBL_INTERLEAVE var)
- tools/jtbl_family_bank.py: the sibling sweep driver (idempotent, revert-on-fail, byte-gated)
- tools/family_remap.py: extract_unit now carries single-line typedefs (jr-function bodies
define local `typedef struct{} Foo_<addr>;` that must template with the body — the
propagation cap for these; additive, byte-gate-protected)
- func_8012ACE0 family: 133/133 siblings BANKED, 0 failures; R22 clean-fleet 136/136
byte-identical; 0 NON_MATCHING (G4)
- metrics: distinct-code 39.1% (50,698 unique fns), instr-weighted 63.0%
- opportunity (has_mid_jr families): 237 total (5,805 members) = 46 small mid/tiny
(771 members, same mechanical pipeline) + 191 substantial (the Fable5 cores, Task 7 paused)
- NEXT: R22 profiling/parallelization; then the other 45 small jr families
|