On Fri, Feb 19, 2016 at 12:53 AM, Egbert S. <cjgd7-q...@yahoo.com> wrote: > 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()? >
I think it is same as the old issue: https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02161.html
