Bind Tier2 candidate clone seed index
This commit is contained in:
parent
4d002d7da8
commit
3d1528adfc
2 changed files with 18 additions and 0 deletions
|
|
@ -1240,6 +1240,15 @@
|
|||
naming branch from cloned bit `[candidate+0xba]`. So the unresolved Tier-2 seam is no longer
|
||||
“find any direct writer to candidate `+0xba/+0xbb`”; it is “find the earlier seed or projection
|
||||
owner that first makes some source/live rows reach that clone path with nonzero bank bytes.”
|
||||
The clone-group seam is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
|
||||
runtime-owned field with many writers: the current direct write set only initializes it to zero
|
||||
in `0x004120b0` and later assigns it in `0x00412d70` as the selected seed-row index that clones
|
||||
should follow. The main consumers match that meaning:
|
||||
`0x0041eba8` compares region-side row key `[row+0x2f2]` against `[candidate+0x794]`,
|
||||
`0x004cccdc` excludes candidates whose seed-row index already matches an active row key, and
|
||||
`0x0050a1cd` keeps the same seeded rows out of one later availability branch. So the remaining
|
||||
Tier-2 seed question is now sharper: which source/live rows become the first seeded rows that let
|
||||
`0x00412d70` propagate nonzero bank bytes within that clone family?
|
||||
That candidate-side table now has a grounded fixed record layout too: each entry is a `0x22`-byte
|
||||
blob with a zero-terminated candidate-name slot at `[entry+0x00..+0x1d]` and one trailing
|
||||
availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue