33013a9b84
The watchpoint plus Canary's source settle it. At the write, the guest context (rsi, per x64_emitter.cc:881) holds 0x8226EAE0, inside sub_8226EAB8. That function is a generic list-node insert: it reads the count at 8(r30), guards against 0x3FFFFFFF overflow, does addi r11,r11,1 / stw r11,8(r30), then links the node. It has 16 callers, so it is a shared container helper. That explains why two static searches missed it. The trigger container at phase+272 EMBEDS an inner list object at +12 -- which is why the push does 'addi r31, r30, 12' -- and the inner object keeps its count at its own +8. So 272 + 12 + 8 = 292 = the watched word, and the instruction is stw r11, 8(r30) with r30 = phase+284. Searching for 'stw rN, 20(rM)' could never have found it. Also resolves the earlier open item on +12: it is the embedded list object, not a list head pointer, which is why it read 0x000A0009 instead of an address. Method note kept: the static hunt assumed the field's offset in the OUTER object would appear in the writing instruction. A watchpoint is indifferent to the addressing form, which is why it was the right tool after two failed offset searches.