Bind infrastructure live-entry walk semantics

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:43:04 -07:00
commit a899622070
3 changed files with 23 additions and 7 deletions

View file

@ -3955,6 +3955,7 @@ fn build_infrastructure_asset_trace_report(
"the side-buffer corpus is disjoint from the placed-structure triplet corpus, so a separate child/rebuild family is more plausible than a compact alias".to_string(), "the side-buffer corpus is disjoint from the placed-structure triplet corpus, so a separate child/rebuild family is more plausible than a compact alias".to_string(),
"direct disassembly now shows 0x00493be0 opening tag family 0x38a5/0x38a6/0x38a7, reading one shared dword into the owner-local 0x90/0x94 lane, iterating each live collection entry, and dispatching every loaded infrastructure record through 0x0048dcf0 before the later follow-on owners run".to_string(), "direct disassembly now shows 0x00493be0 opening tag family 0x38a5/0x38a6/0x38a7, reading one shared dword into the owner-local 0x90/0x94 lane, iterating each live collection entry, and dispatching every loaded infrastructure record through 0x0048dcf0 before the later follow-on owners run".to_string(),
"direct disassembly now shows 0x00518140 resolving a non-direct live entry through the tombstone bitset and then returning the first dword of a 12-byte row from [collection+0x3c] for the 0x38a5 path".to_string(), "direct disassembly now shows 0x00518140 resolving a non-direct live entry through the tombstone bitset and then returning the first dword of a 12-byte row from [collection+0x3c] for the 0x38a5 path".to_string(),
"direct disassembly now also shows 0x00493be0 iterating live-entry ordinals through 0x00518380(ordinal, 0), converting each ordinal to a live id, then resolving that live id through 0x00518140 before handing the resulting payload pointer to 0x0048dcf0".to_string(),
"direct disassembly now shows 0x00518680 loading the non-direct collection header, tombstone bitset, and live-id-bound-scaled 12-byte tables for the non-direct path before 0x00493be0 starts iterating".to_string(), "direct disassembly now shows 0x00518680 loading the non-direct collection header, tombstone bitset, and live-id-bound-scaled 12-byte tables for the non-direct path before 0x00493be0 starts iterating".to_string(),
"local .rdata at 0x005cfd00 now also proves the infrastructure child table uses the shared tagged callback strip directly: slot +0x40 = 0x455fc0, slot +0x48 = 0x455870, and slot +0x4c = 0x455930".to_string(), "local .rdata at 0x005cfd00 now also proves the infrastructure child table uses the shared tagged callback strip directly: slot +0x40 = 0x455fc0, slot +0x48 = 0x455870, and slot +0x4c = 0x455930".to_string(),
"direct disassembly now shows 0x0048a1e0 cloning the first child triplet bands through 0x52e880/0x52e720, destroying the prior child, seeding a new literal Infrastructure child through 0x455b70 with payload seed 0x5c87a8, attaching through 0x5395d0 or 0x53a5d0, and republishing the two bands through 0x52e8b0/0x530720".to_string(), "direct disassembly now shows 0x0048a1e0 cloning the first child triplet bands through 0x52e880/0x52e720, destroying the prior child, seeding a new literal Infrastructure child through 0x455b70 with payload seed 0x5c87a8, attaching through 0x5395d0 or 0x53a5d0, and republishing the two bands through 0x52e8b0/0x530720".to_string(),
@ -3962,7 +3963,8 @@ fn build_infrastructure_asset_trace_report(
"the smaller attach primitive 0x00490a3c no longer looks like the semantic fork by itself: it just allocates one literal Infrastructure child, seeds it through 0x455b70 with caller-provided stem input, attaches it through 0x5395d0, seeds position lanes through 0x539530/0x53a5b0, and optionally caches it as primary child".to_string(), "the smaller attach primitive 0x00490a3c no longer looks like the semantic fork by itself: it just allocates one literal Infrastructure child, seeds it through 0x455b70 with caller-provided stem input, attaches it through 0x5395d0, seeds position lanes through 0x539530/0x53a5b0, and optionally caches it as primary child".to_string(),
], ],
blockers: vec![ blockers: vec![
"which fields inside the non-direct 12-byte live-entry rows back the payload pointer, child-count stream, saved primary-child ordinal stream, and per-child shared tagged callback records".to_string(), "which remaining dwords inside the non-direct 12-byte live-entry rows still matter after the first dword resolves the per-entry payload pointer".to_string(),
"how the payload streams reached through 0x00518380 -> 0x00518140 align with the embedded 0x55f1 name-pair groups and compact-prefix regimes surfaced by the save-side probe".to_string(),
"which restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(), "which restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
], ],
}, },
@ -22068,6 +22070,12 @@ mod tests {
&& line.contains("[collection+0x3c]") && line.contains("[collection+0x3c]")
}) })
); );
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x00518380") && line.contains("ordinal"))
);
assert_eq!(trace.branches[0].status, "grounded_separate_owner_seam"); assert_eq!(trace.branches[0].status, "grounded_separate_owner_seam");
assert_eq!(trace.branches[1].status, "disproved_by_grounded_probe"); assert_eq!(trace.branches[1].status, "disproved_by_grounded_probe");
} }

View file

@ -2924,8 +2924,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`[collection+0x3c]`, while `0x00518680` loads the non-direct collection header, tombstone bitset, `[collection+0x3c]`, while `0x00518680` loads the non-direct collection header, tombstone bitset,
and live-id-bound-scaled `12`-byte tables before `0x00493be0` starts iterating. So the remaining and live-id-bound-scaled `12`-byte tables before `0x00493be0` starts iterating. So the remaining
infrastructure mapping problem is no longer “which generic collection helper is involved?” but infrastructure mapping problem is no longer “which generic collection helper is involved?” but
which fields inside those `12`-byte live-entry rows drive the child-count stream, saved how those helpers compose in the actual load loop: `0x00493be0` now reads as an
primary-child ordinal stream, and per-child tagged callback payloads. ordinal-to-live-id-to-payload-pointer walk through `0x00518380(ordinal, 0)` then
`0x00518140(live_id)`. That narrows the remaining infrastructure mapping problem further:
the first dword of each `12`-byte live-entry row is already spoken for as the per-entry payload
pointer, so the next unknowns are which remaining dwords in that row still matter and how the
payload streams they point to align with the save-side `0x55f1` name-pair groups and compact
prefix regimes.
The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with `Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining `+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining

View file

@ -57,10 +57,13 @@ Working rule:
remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore
path at all. Direct disassembly now also shows `0x00518140` resolving a non-direct live entry by path at all. Direct disassembly now also shows `0x00518140` resolving a non-direct live entry by
tombstone bitset and then returning the first dword of a `12`-byte row from `[collection+0x3c]`, tombstone bitset and then returning the first dword of a `12`-byte row from `[collection+0x3c]`,
while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating. So while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating, and
the next infrastructure question is which fields inside those `12`-byte live-entry rows map to `0x00493be0` itself now reads as an ordinal-to-live-id-to-payload-pointer walk through
the child count, saved primary-child ordinal, and per-child `+0x40` payload callbacks inside `0x00518380(ordinal, 0)` then `0x00518140(live_id)`. So the next infrastructure question is no
that direct path. longer “which row owns the payload pointer?” but which remaining dwords in those `12`-byte
live-entry rows still matter after the first dword resolves the per-entry payload pointer, and
how those payload streams align with the embedded `0x55f1` name-pair groups and compact-prefix
regimes.
- The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the - The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with `Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining `+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining