On 12/2/21 01:54, Paul Gofman wrote:
On 12/1/21 19:49, Jinoh Kang wrote:
Example scenario, if code_mem == 0x123FF0:
- LEAQ RAX, [RIP + 0x1000] | RAX = 0x124FF7 (0x123FF0 + 7 + 0x1000)
- ANDQ RAX, ~0xFFF | RAX = 0x124000 (0x124FF7 & ~0xFFF)
- SUBQ RAX, 8 | RAX = 0x123FF8 (0x124FF0 - 8)
- MOVQ [RAX], RSP
- MOVQ RSP, RAX | RSP = 0x123FF8
- PUSH R8 | RSP = 0x123FF0
- PUSH RBX | RSP = 0x123FE8 <--- [[overflow]]
code_mem is always page-aligned though, so the overflow won't happen. But in that case I suppose andq gives a false impression that the address might not be page-aligned.
I didn't want to rely that the rip is exactly at the code_mem start and not a few bytes ahead.
I agree that hard-coding the offset would be fragile. Also, code_mem's alignment might change in the future.
In that case, how about relaxing the masking out (e.g. ~0xF instead of ~0xFFF) so as to avoid the supposed underflow? Again, this is merely a suggestion; the code would work as-is due to currently guaranteed properties on code_mem. It's not that I'm a Wine maintainer either...
Perhaps it ignores CS being set to any other value (e.g. 32-bit compat segment?) or maybe selectively use IRETQ. I hope no usermode anti-debugging/anti-cheat would rely on this...
Some might, in theory, or maybe rely on one of the numerous other neat things around this stuff. I am just not sure we should (or can) mind every bit of special cases we can think of before we know that anything relies on that.
You're right. Also Windows could break those special cases anytime in the future.
Even though implementation of exact emulation might prove unnecessary, I suppose some thorough unit tests (with todo_wine) might aid in diagnosing future incompatibility issues and pinpoint which behaviour was left unimplemented. But that's for a separate patch set, and I could, well, just submit it myself ;)