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

Ground infrastructure composition chooser strip

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 15:03:20 -07:00
commit 544dbf3f8a
3 changed files with 44 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -3001,6 +3001,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x0002 / 0xff` as the grounded save-side bridge-specific two-child candidate class above
`0x0048a1e0/0x0048dcf0`, with the remaining unknown narrowed to the upstream chooser that emits
that class before the attach/rebuild path runs.
That upstream chooser is grounded now too: direct disassembly of `0x004a2c80..0x004a37de`
shows a dense infrastructure composition strip repeatedly calling `0x0048a1e0`, branching on
`[this+0x226]`, selector bytes `[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and
lookup tables `0x621a44..0x621a9c`, then routing follow-on through
`0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining infrastructure question is no
longer “is there an upstream chooser?” but “which lookup-table families inside that chooser map
to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00` BallastCap class?”.
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