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

Bind infrastructure live-entry walk semantics

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

9
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
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,
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

11
docs/rehost-queue.md
View file

@ -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