abed25fd67
The previous section withdrew this localisation for resting on a stale PPCContext. It is now re-established by a sound method. Xenia has a CPU cvar, emit_source_annotations, that makes MarkSourceOffset emit "nop; nop; mov eax,<guest_address>; nop; nop" at EVERY guest instruction boundary -- 90 90 B8 xx xx xx xx 90 90 in the code bytes. So the guest PC reads straight out of memory around rip, with no context and no offset guessing. Dumping backwards from rip gives a clean run of them -- 0x82457874, 78, 7C, 80, 84 -- and the annotation immediately before rip is 0x824578A0. That is `sth r6, 0(r9)` inside sub_82457780: the exact instruction predicted from the disassembly last time, now reached independently. The loop advances r11 by 8 and terminates on `bne cr6` -- exact inequality. If r31 - r7 is not a positive multiple of 8, the comparison never becomes equal and the loop never exits. And the thread is genuinely running: over 4 s, Main XThread consumed 890 ms of CPU, the top of any thread, with the process at ~238%. A spin, not a block. One bad metric recorded: I tried to show the loop marching through memory by watching the last non-zero byte above 0x70200000. It never moved -- but that statistic saturates in an already-written region, so it could not have moved. Not evidence either way, though it briefly looked like a refutation. Open and now narrow: what makes r31 - r7 non-congruent to 0 mod 8. r7 comes from 0(r30), r31 is the container end, and r3 holds a fresh buffer from 0x824F7240 -- read those three from HOST registers at the freeze.