On 29.05.2020 14:24, Andrew Cooper wrote: > On 25/05/2020 15:26, Jan Beulich wrote: >> Unlike similarly encoded insns these don't write their memory operands, > > "write to their". > >> and hence x86_is_mem_write() should return false for them. However, >> rather than adding special logic there, rework how their emulation gets >> done, by making decoding attributes properly describe the r/o nature of >> their memory operands. > > Describe how? I see you've change the order of operands encoding, but > then override it back?
There's no overriding back, I don't think: I change the table entries for opcodes 0x38 and 0x39, with no other adjustments the the attributes later on. For the other opcodes I leave the table entries as they are, and override the attributes for the specific sub-cases (identified by ModRM.reg). For opcodes 0x38 and 0x39 the change of the table entries implies changing the order of operands as passed to emulate_2op_SrcV(), hence the splitting of the cases in the main switch(). I didn't think this was necessary to spell out in the commit message, but of course I can re-use most of the text above and add it into there, if you think that would help. Jan
