761dcd004c
From Canary's own source (x64_emitter.cc:881) GetContextReg() returns rsi, so at any JIT instruction %rsi is the PPCContext* -- which is also why the faulting instruction read 0x110(%rsi), a guest register load. That is the way past the watchpoint's ceiling: the guest register file is available at the write, and a 0x82xxxxxx word picked out of it resolves against sylpheed.db to name the caller. trigger_watch.sh now dumps x/128wx instead of a useless host backtrace. The re-run then failed for an unrelated and unexplained reason: it reached flight, the pilot bound, the guest was animating, and find_mission returned NOTFOUND. Narrowed: the .ssb header is absent from guest memory (0 hits where earlier runs hit immediately), ADN110 is absent too, but the manifest string 'Stage02.ssb' IS present at 0xBDA6C50B. So memory is readable and the manifest is loaded while the script is not, in a mission that is flying. No explanation offered. The cheap discriminator for next time is to poll for the header from the moment flight starts and record when it appears, instead of sampling once.