Bind non-direct infrastructure collection helpers

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:41:21 -07:00
commit 647c0e9265
3 changed files with 32 additions and 5 deletions

View file

@ -3906,10 +3906,14 @@ fn build_infrastructure_asset_trace_report(
"[this+0x206/+0x20a/+0x20e] route-entry resolver fields".to_string(),
"[this+0x1e2/+0x1e6/+0x1ea] published anchor triplet".to_string(),
"child list [this+0x75] under the Infrastructure owner".to_string(),
"non-direct live-entry table [collection+0x3c] with 12-byte rows".to_string(),
];
let known_bridge_helpers = vec![
"0x00493be0 tagged 0x38a5/0x38a6/0x38a7 collection load owner".to_string(),
"0x00455a50 raw vtable slot +0x40 dispatch wrapper with global bridge reset".to_string(),
"0x00518140 indexed_collection_resolve_live_entry_payload_pointer_by_live_id".to_string(),
"0x00518380 indexed_collection_find_nth_live_entry_id".to_string(),
"0x00518680 indexed_collection_load_header_bitset_and_non_direct_tables".to_string(),
"0x005395d0 shared child-attach list owner".to_string(),
"0x00539530 shared position-lane seed helper".to_string(),
"0x0053a5b0 shared third position-lane seed helper".to_string(),
@ -3950,13 +3954,15 @@ fn build_infrastructure_asset_trace_report(
"atlas already bounds these helpers under the literal Infrastructure owner".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 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 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(),
"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 also shows the outer owner at 0x0048dcf0 reading a child count plus optional primary-child ordinal from the tagged stream through 0x531150, zeroing [this+0x08], dispatching each fresh child through 0x455a50 -> vtable slot +0x40, culling ordinals above 5, and restoring cached primary-child slot [this+0x248] from the saved ordinal".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![
"which exact 0x38a5 rows or compact-prefix regimes map to the child count, saved primary-child ordinal, and per-child shared tagged callback records".to_string(),
"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 restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
],
},
@ -22044,14 +22050,24 @@ mod tests {
let trace = build_infrastructure_asset_trace_report(&analysis);
assert!(trace.side_buffer_present);
assert_eq!(trace.triplet_alignment_overlap_count, 0);
assert_eq!(trace.known_owner_bridge_fields.len(), 4);
assert_eq!(trace.known_bridge_helpers.len(), 7);
assert_eq!(trace.known_owner_bridge_fields.len(), 5);
assert_eq!(trace.known_bridge_helpers.len(), 10);
assert_eq!(trace.next_owner_questions.len(), 3);
assert_eq!(trace.candidate_consumer_hypotheses.len(), 3);
assert_eq!(
trace.candidate_consumer_hypotheses[0].status,
"highest_priority_static_mapping_target"
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| {
line.contains("0x00518140")
&& line.contains("12-byte row")
&& line.contains("[collection+0x3c]")
})
);
assert_eq!(trace.branches[0].status, "grounded_separate_owner_seam");
assert_eq!(trace.branches[1].status, "disproved_by_grounded_probe");
}

View file

@ -2919,6 +2919,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. That means
the `0x38a5` side-buffer seam is now a proven direct upstream feed into the child-stream restore
owner rather than only a candidate cache or serializer-side neighbor.
The collection helpers above that handoff are bounded now too: `0x00518140` resolves a non-direct
live entry through the tombstone bitset and returns the first dword of a `12`-byte row from
`[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
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
primary-child ordinal stream, and per-child tagged callback payloads.
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
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining

View file

@ -55,8 +55,12 @@ Working rule:
`0x38a5/0x38a6/0x38a7`, and it feeds each live infrastructure record straight into
`0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. So the
remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore
path at all; it is which exact rows or compact-prefix regimes map to the child count, saved
primary-child ordinal, and per-child `+0x40` payload callbacks inside that direct path.
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]`,
while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating. So
the next infrastructure question is which fields inside those `12`-byte live-entry rows map to
the child count, saved primary-child ordinal, and per-child `+0x40` payload callbacks inside
that direct path.
- 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
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining