|
||
|---|---|---|
|
|
||
|
|
我在内嵌汇编里面试了一下，事实是32位兼容模式下进行mov eax, [esp + n]之类的操作，会把rax高32位自动清零，也就是说不论是不是32位兼容模式，对低32位寄存器进行mov操作，高32位都会被自动扩展为0 #define db(a) __asm __emit(a)
DWORD a = 1; __asm { push 0x33 push x64Enter1 retf x64Enter1: db(0x48) db(0x33) db(0xC0) //xor rax, rax db(0x48) db(0xF7) db(0xD0) //not rax push x64Exit1 db(0xC6) db(0x44) db(0x24) db(0x04) db(0x23) //mov byte ptr[rsp + 4], 023h retf x64Exit1: mov eax, a push 0x33 push x64Enter2 retf x64Enter2: db(0x48) db(0xC1) db(0xE8) db(0x20) //shr rax, 20h push x64Exit2 db(0xC6) db(0x44) db(0x24) db(0x04) db(0x23) //mov byte ptr[rsp + 4], 023h retf x64Exit2: mov a, eax } printf("%X\n", a); 这段代码我在VS上试过，结果为0
最后于 2019-6-2 00:23
被hhkqqs编辑
，原因：
|
|
|
|
||
|
|
我上面的asm先切换到64位，让rax为0xFFFFFFFFFFFFFFFF，然后切回32位，对eax赋值为dword ptr[esp]，然后切回64位让rax右移32位，按理来说这时候eax应该是0xFFFFFFFF，但结果却是0（如果注释掉mov eax, a，结果是0xFFFFFFFF没毛病），说明32位下mov的赋值直接把rax高32位清零了，本来这种现象我只在64位模式下见过，没想到32位模式居然也是这样 |
|
|
|
你VS是怎么用内联汇编的? 我x64用__asm 提示无法使用内联汇编. 是需要设置什么吗? |
|
|
|
我用的win32平台，上面那个代码是用来32位切换到64位写汇编的 |
|
|
|
66666
|
|
|
|
使用Windbg跟踪一下就很容易看到结果：
查询微软的文档（x64指令）可以看出，使用mov指令传送32位数据将会自动零扩展高32位，并没有说在哪个特定的处理器模式。
|
|
|
|
巨硬和Intel的文档我都看过，他们明显只针对64位模式下没有movzxd给出零扩展的说法，压根没提过86兼容模式也会影响到完全不可见的高32位 |
|
|
|
||
|
|
这可能就是传说中的“未定义行为” |
|
|
|
||
|
|
你说的这些都是手册上的，完全没解释我主贴说的这种现象，86兼容模式能影响寄存器的高32位从未在任何官方手册出现过 |
|
|
|
其实严格来说，不是86兼容模式，而是Windows下cs=23h表示32位代码段 mov eax, 1 32位代码段模式下对32位寄存器的操作会视为全长 而这时候64位CPU内部会自动对齐到8字节的rax，只是我们看不到高32位 64位CPU也只有这样设计才能支持32位程序 |
|
|
|
我也感觉是设计上统一了两种模式部分指令的实现机制，只不过Intel没有写进手册而已 |
|
|
|
又仔细调试了下大佬的代码: 一. 不屏蔽mov eax,a 源码 #define db(a) __asm __emit(a) DEBUG版调试结果:
一. 屏蔽mov eax,a 源码 #define db(a) __asm __emit(a) DEBUG版调试结果
rax寄存器的高32位对于WOW64兼容模式下运行的32位进程仍然是不可见的(在mov dword ptr ss:[ebp-c],eax这下个断点就可以看到eax的准确值了，我这个是调试得太块，直接F9步过了，但逻辑正确，只管结果就行了)，这里是通过改变段选择子并进行远返回来进行x86/x64切换得出的。 好了！开会去咯！
最后于 2020-11-2 11:44
被低调putchar编辑
，原因：
|
|
hzqst
ezrealik
