Tighten region payload callback semantics

This commit is contained in:
Jan Petykiewicz 2026-04-18 19:20:53 -07:00
commit 5bc7b3090e
2 changed files with 6 additions and 3 deletions

View file

@ -4536,7 +4536,7 @@ fn build_region_service_trace_report(
"the checked-in function map already grounds 0x0041f5c0 as the per-record load slot that reloads the tagged payload through 0x00455fc0 and then rebuilds profile collection [region+0x37f]".to_string(), "the checked-in function map already grounds 0x0041f5c0 as the per-record load slot that reloads the tagged payload through 0x00455fc0 and then rebuilds profile collection [region+0x37f]".to_string(),
"constructor-side evidence now proves the latches are initialized locally, so the remaining gap can legitimately be framed as post-construction restore or rebuild".to_string(), "constructor-side evidence now proves the latches are initialized locally, so the remaining gap can legitimately be framed as post-construction restore or rebuild".to_string(),
"direct disassembly of 0x0041f590/0x0041f5b0 now proves the world-region vtable root is 0x005c9a28, so the 0x00455fc0 dispatch at slot +0x48 lands on 0x00455870 and the serializer sibling at +0x4c lands on 0x00455930".to_string(), "direct disassembly of 0x0041f590/0x0041f5b0 now proves the world-region vtable root is 0x005c9a28, so the 0x00455fc0 dispatch at slot +0x48 lands on 0x00455870 and the serializer sibling at +0x4c lands on 0x00455930".to_string(),
"direct disassembly of 0x00455870/0x00455930 now shows that callback pair only restores and serializes two triplet-like three-lane scalar bands through 0x531150/0x531030 plus 0x530720/0x52e8b0, not [region+0x276/+0x302/+0x316]".to_string(), "direct disassembly of 0x00455870/0x00455930 now shows that callback pair only restores and serializes two helper-local three-lane scalar bands: 0x00455870 reads six dwords through 0x531150 and forwards them to 0x530720 -> [helper+0x1e2/+0x1e6/+0x1ea] and 0x52e8b0 -> [helper+0x4b/+0x4f/+0x53], while 0x00455930 writes that same pair back through 0x531030; it still does not touch acquisition-side lanes [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),
"direct disassembly now tightens the rest of 0x00455fc0 too: after the +0x48 callback it only runs 0x0052ebd0 to read two one-byte generic flags through 0x531150 into base object bytes [this+0x20], [this+0x8d], [this+0x5c..+0x61], [this+0x1ee], [this+0x1fa], and [this+0x3e], then opens 0x55f3 only for span accounting before returning, so the missing region latches are not hiding in the remainder of 0x00455fc0 either".to_string(), "direct disassembly now tightens the rest of 0x00455fc0 too: after the +0x48 callback it only runs 0x0052ebd0 to read two one-byte generic flags through 0x531150 into base object bytes [this+0x20], [this+0x8d], [this+0x5c..+0x61], [this+0x1ee], [this+0x1fa], and [this+0x3e], then opens 0x55f3 only for span accounting before returning, so the missing region latches are not hiding in the remainder of 0x00455fc0 either".to_string(),
"direct disassembly of 0x00421510 now also shows the exact tagged loop shape: it opens 0x5209, reads 0x520a, iterates live entry ordinals through 0x518380/0x518140, seeds a stack-local world-region vtable helper through 0x0041f590/0x0041f5b0, dispatches each loaded record through slot +0x40, and only then closes 0x520b".to_string(), "direct disassembly of 0x00421510 now also shows the exact tagged loop shape: it opens 0x5209, reads 0x520a, iterates live entry ordinals through 0x518380/0x518140, seeds a stack-local world-region vtable helper through 0x0041f590/0x0041f5b0, dispatches each loaded record through slot +0x40, and only then closes 0x520b".to_string(),
"direct disassembly of 0x0041f5c0 now also shows its post-0x00455fc0 work is local to the profile collection path: it clamps [region+0x31b] back to 1.0f when needed, zeroes [region+0x317], allocates one 0x88-sized helper through 0x53b070/0x518b90, stores it at [region+0x37f], loads that helper through 0x518680, and clears [region+0x385] before returning".to_string(), "direct disassembly of 0x0041f5c0 now also shows its post-0x00455fc0 work is local to the profile collection path: it clamps [region+0x31b] back to 1.0f when needed, zeroes [region+0x317], allocates one 0x88-sized helper through 0x53b070/0x518b90, stores it at [region+0x37f], loads that helper through 0x518680, and clears [region+0x385] before returning".to_string(),

View file

@ -537,8 +537,11 @@ Working rule:
- Direct disassembly now closes that callback identity too: `0x0041f590/0x0041f5b0` prove the - Direct disassembly now closes that callback identity too: `0x0041f590/0x0041f5b0` prove the
world-region vtable root is `0x005c9a28`, so the `0x00455fc0` dispatch at slot `+0x48` lands on world-region vtable root is `0x005c9a28`, so the `0x00455fc0` dispatch at slot `+0x48` lands on
`0x00455870` and the serializer sibling at `+0x4c` lands on `0x00455930`. Those two callbacks `0x00455870` and the serializer sibling at `+0x4c` lands on `0x00455930`. Those two callbacks
only restore and serialize two triplet-like three-lane scalar bands through only restore and serialize two helper-local three-lane scalar bands: `0x00455870` reads six
`0x00531150/0x00531030` plus `0x00530720/0x0052e8b0`; they still do not touch dwords through `0x00531150` and forwards them to `0x00530720 -> [helper+0x1e2/+0x1e6/+0x1ea]`
and `0x0052e8b0 -> [helper+0x4b/+0x4f/+0x53]`, while `0x00455930` writes that same pair back
through `0x00531030`; they still do not touch acquisition-side lanes
`[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`, and they still do not touch
`[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later `[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later
owner that rebuilds those latches or the separate tagged body seam that persists them. owner that rebuilds those latches or the separate tagged body seam that persists them.
- The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs - The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs