I have here a case (over at GitHub unicorn-engine/unicorn tests/unit/test_tb_x86.c) that is running a stack-based Alpha-Mixed sample that contains an instruction that changed an operand of the next instruction, the one that QEMU does not detect nor execute properly (even with TARGET_HAS_PRECISE_SMC define compiled in). Stack-based writeable MemoryRegion "pc.ram" starts at 0x60000000.
Live trace of QEMU is:
ecx = 0x5ffffff8
# Modify code location 60000028 to 0x10 from 0x51
60000021 304130 xor byte ptr [ocx + 0x30], al
60000024 41 inc ecx
60000025 6b414151 imul eax, dword ptr [ecx + 0x41], 0x51
In the notdirty_mem_write(), it does a tb_invalidate_phys_page_fast() firstly before writing directly to the "pc.ram".
As a result, the newly reconstructed TB rebuilds the 'imul' micro-operation sequence , but still retrieving the original 0x51 immediate byte operand (and not the expected 0x10).
Interestingly, doing a read operation of the exact 0x60000028 byte retrieves that updated (and correct) 0x10.
Could it be that in the notdirty_mem_write(), that stX_p() must be performed firstly before the tb_invalidate_phys_page_fast()?