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

Rule down grouped opcode restore ownership

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 00:00:37 -07:00
commit e3c29ae904
2 changed files with 19 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/rehost-queue.md
View file

@ -220,12 +220,18 @@ Working rule:
per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the
cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct
`[site+0x276]` republisher
- the grouped-opcode family is ruled down too:
current direct caller census only reaches `0x00431b20` from scenario runtime-effect service
`0x004323a0 -> 0x00432f40` through direct call `0x00432317`, so `0x0061039c` currently reads
as a live runtime-effect application lane rather than the missing persisted restore owner for
`[site+0x276]`
- the remaining owner-company question is therefore narrower than “find any replay seam”:
identify which non-transport persisted source family outside the currently bounded direct
allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
`0x00413280` cached-source bridge, and the checked ordinary replay strip
`0x00444690 -> 0x004133b0 -> 0x0040ee10` feeds the tuple or companion restore calls that are
sufficient to repopulate `[site+0x276]` for shellless acquisition
`0x00413280` cached-source bridge, the checked ordinary replay strip
`0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the live runtime-effect dispatcher
`0x00431b20` feeds the tuple or companion restore calls that are sufficient to repopulate
`[site+0x276]` for shellless acquisition
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`