jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind infrastructure side-buffer load path

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 13:28:15 -07:00
commit 0d3e6c598d
3 changed files with 40 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

18
crates/rrt-runtime/src/smp.rs
View file

@ -3886,6 +3886,7 @@ fn build_infrastructure_asset_trace_report(
.filter(|summary| summary.primary_name.contains("TrackCap"))
.count();
let atlas_candidate_consumers = vec![
"0x00493be0 infrastructure tagged side-buffer collection load owner".to_string(),
"0x0048a1e0 infrastructure child attach helper".to_string(),
"0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
"0x0048dd50 infrastructure child rebuild loop".to_string(),
@ -3903,6 +3904,7 @@ fn build_infrastructure_asset_trace_report(
"child list [this+0x75] under the Infrastructure owner".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(),
"0x005395d0 shared child-attach list owner".to_string(),
"0x00539530 shared position-lane seed helper".to_string(),
@ -3912,8 +3914,8 @@ fn build_infrastructure_asset_trace_report(
"0x0048e140 / 0x0048e160 / 0x0048e180 route-entry resolver helpers".to_string(),
];
let next_owner_questions = vec![
"Which upstream owner materializes the tagged child stream that 0x0048dcf0 restores before the later 0x0048dd50 rebuild loop runs?".to_string(),
"Does the 0x38a5 compact-prefix/name-pair seam feed that upstream child-stream materializer, the direct 0x00490a3c payload-stem path, or only later route/local-runtime refresh?".to_string(),
"Which exact 0x38a5 rows or compact-prefix regimes feed the child count and optional primary-child ordinal that 0x0048dcf0 restores before the later rebuild loop runs?".to_string(),
"Which 0x38a5 embedded name-pair groups survive into the per-child vtable +0x40 payload callbacks dispatched through 0x00455a50?".to_string(),
"Is cached primary-child slot [this+0x248] the first owner-visible bridge from the restored child stream into route-entry rebuild?".to_string(),
];
let candidate_consumer_hypotheses = vec![
@ -3928,6 +3930,7 @@ fn build_infrastructure_asset_trace_report(
"possible_consumer_family".to_string()
},
candidate_consumers: vec![
"0x00493be0 infrastructure tagged side-buffer collection load owner".to_string(),
"0x0048a1e0 infrastructure child attach helper".to_string(),
"0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
"0x0048dd50 infrastructure child rebuild loop".to_string(),
@ -3942,13 +3945,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(),
"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 upstream owner materializes the tagged child stream that 0x0048dcf0 consumes".to_string(),
"whether the 0x38a5 compact-prefix/name-pair seam feeds that materializer or only a separate payload/cache lane".to_string(),
"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 restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
],
},
SmpServiceConsumerHypothesis {
@ -3965,10 +3970,11 @@ fn build_infrastructure_asset_trace_report(
],
evidence: vec![
"atlas already bounds the serializer/load strip around the Infrastructure owner and the same 0x55f1/0x55f2/0x55f3 tag family".to_string(),
"local .rdata at 0x005cfd00 now proves the infrastructure child vtable points straight at 0x455fc0/0x455870/0x455930 for the load, triplet-restore, and serializer slots".to_string(),
"the save-side side-buffer carries embedded dual-name rows plus compact prefixes, which is compatible with a serializer-side bridge".to_string(),
],
blockers: vec![
"whether the side-buffer is a direct serialized payload or one rebuild/cache layer above it".to_string(),
"which exact 0x38a5 rows belong to shared 0x55f1/0x55f2/0x55f3 child records versus outer collection metadata".to_string(),
],
},
SmpServiceConsumerHypothesis {
@ -22006,7 +22012,7 @@ mod tests {
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(), 6);
assert_eq!(trace.known_bridge_helpers.len(), 7);
assert_eq!(trace.next_owner_questions.len(), 3);
assert_eq!(trace.candidate_consumer_hypotheses.len(), 3);
assert_eq!(

18
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -2914,6 +2914,16 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
and restores cached primary-child slot `[this+0x248]` from the saved ordinal. So the rebuild
strip is consuming an already-materialized child stream rather than parsing the compact side
buffer directly.
The upstream handoff is explicit now too: `0x00493be0` is the tagged collection load owner over
`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. 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 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
infrastructure problem is row-to-record mapping inside the `0x38a5` stream, not identifying the
per-child loader family.
The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
`Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The
@ -2924,10 +2934,10 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
then republishes the two sampled triplet bands through `0x0052e8b0` and `0x00530720` after
attaching through `0x005395d0`. The non-clone branch still seeds the same literal
`Infrastructure` child but attaches through `0x0053a5d0` instead. That means the next unknown is
no longer whether this strip owns the child/rebuild seam at all, but which upstream owner
materializes the child stream that `0x0048dcf0` consumes, and whether the side-buffer prefix
groups feed that materializer, the direct payload-stem lane, or only the later
route/local-runtime family.
no longer whether this strip owns the child/rebuild seam at all, but which exact `0x38a5` rows
or compact-prefix regimes map to the child count, saved primary-child ordinal, and per-child
`+0x40` payload callbacks inside that direct load path, and which restored child fields still
retain those embedded name-pair semantics before the later route/local-runtime family runs.
The
remaining closure target above the grounded `0x38a5` side-buffer seam is therefore narrower now:
the next safe static pass should start at this exact attach/rebuild strip, not at the whole

16
docs/rehost-queue.md
View file

@ -51,12 +51,24 @@ Working rule:
and restores cached primary-child slot `[this+0x248]` from the saved ordinal. That means the
child/rebuild loop is consuming an already-materialized child stream rather than parsing the
`0x38a5` compact-prefix seam directly.
- The upstream handoff is grounded now too: `0x00493be0` is the tagged collection load owner over
`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.
- 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
infrastructure frontier is row-to-record mapping inside `0x38a5`, not “which loader family does
this child use?”.
- The smaller helper `0x00490a3c` is narrower now too: it allocates one literal `Infrastructure`
child, seeds it through `0x00455b70` with caller-provided stem input, attaches it through
`0x005395d0`, seeds position lanes through `0x00539530/0x0053a5b0`, and optionally caches it as
the primary child. So the next concrete infrastructure question is which upstream owner
materializes the child stream that `0x0048dcf0` consumes, and whether `0x38a5` feeds that owner
or only a separate payload/cache lane.
maps the direct `0x38a5` rows into the child count, primary-child ordinal, and per-child payload
callbacks consumed by `0x0048dcf0`, and which restored child fields still retain those embedded
name-pair semantics before route/local-runtime follow-ons take over.
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded