Bind infrastructure live-entry walk semantics
This commit is contained in:
parent
647c0e9265
commit
a899622070
3 changed files with 23 additions and 7 deletions
|
|
@ -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(),
|
||||
"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 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(),
|
||||
"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(),
|
||||
|
|
@ -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(),
|
||||
],
|
||||
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(),
|
||||
],
|
||||
},
|
||||
|
|
@ -22068,6 +22070,12 @@ mod tests {
|
|||
&& 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[1].status, "disproved_by_grounded_probe");
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
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.
|
||||
how those helpers compose in the actual load loop: `0x00493be0` now reads as an
|
||||
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
|
||||
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
|
||||
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
|
||||
|
|
|
|||
|
|
@ -57,10 +57,13 @@ Working rule:
|
|||
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
|
||||
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.
|
||||
while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating, and
|
||||
`0x00493be0` itself now reads as an ordinal-to-live-id-to-payload-pointer walk through
|
||||
`0x00518380(ordinal, 0)` then `0x00518140(live_id)`. So the next infrastructure question is no
|
||||
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
|
||||
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
|
||||
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue