64位下mov $0x80000000,%eax会不会影响%rax的高32位？

qtdszws

我觉得不会影响，但是调试发现会，全部清零，什么道理？

mik

是不会影响的

qtdszws

那么下面的调试结果如何解释?

1. 
   
2. (gdb)
   
3. 0x000000000042f2de      4671            exp->X_add_number
   
4. 1: x/i $rip
   
5. 0x42f2de <i386_immediate+536>:  mov    $0x80000000,%eax
   
6. (gdb) p $rax
   
7. $1 = 0
   
8. (gdb) set $rax=-1
   
9. (gdb) p /x $rax
   
10. $3 = 0xffffffffffffffff
    
11. (gdb) si
    
12. 0x000000000042f2e3      4671            exp->X_add_number
    
13. 1: x/i $rip
    
14. 0x42f2e3 <i386_immediate+541>:  xor    0x10(%rdx),%rax
    
15. (gdb) p /x $rax
    
16. $4 = 0x80000000
    
17. (gdb)  
    

复制代码

mik

不懂用 gdb

问题在哪？

qtdszws

在指令mov $0x80000000,%eax之前，我设置了%rax的值，是-1,执行该指令后，再查看%rax的值，是0x80000000.说明高32位被冲掉了

mik

汗～

还真有这回事，连 AMD / Intel 的官方文档都没讲清楚


下面是我在 bochs　调试的情况：

1. Next at t=177905194
   
2. rax: 0xffff8000:00400000 rcx: 0x00000000:00000000
   
3. rdx: 0x00000000:00000000 rbx: 0xfffff000:fffff000
   
4. rsp: 0xfffff000:fffffff0 rbp: 0x00000000:0000b028
   
5. rsi: 0x00000000:ffff9000 rdi: 0x00000000:000b9900
   
6. r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
   
7. r10: 0x0000ee00:00000000 r11: 0xffff9000:00051008
   
8. r12: 0x00000000:00000000 r13: 0x00000000:00000000
   
9. r14: 0x00000000:00000000 r15: 0x00000000:00000000
   
10. rip: 0xffff8000:004000c8
    
11. eflags 0x00000246: id vip vif ac vm rf nt IOPL=0 of df IF tf sf ZF af PF cf
    
12. (0) [0x1f4000c8] 0058:ffff8000004000c8 (unk. ctxt): mov eax, 0x80000000 ; b800000080
    
13. <bochs:6> s
    
14. Next at t=177905195
    
15. rax: 0x00000000:80000000 rcx: 0x00000000:00000000
    
16. rdx: 0x00000000:00000000 rbx: 0xfffff000:fffff000
    
17. rsp: 0xfffff000:fffffff0 rbp: 0x00000000:0000b028
    
18. rsi: 0x00000000:ffff9000 rdi: 0x00000000:000b9900
    
19. r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
    
20. r10: 0x0000ee00:00000000 r11: 0xffff9000:00051008
    
21. r12: 0x00000000:00000000 r13: 0x00000000:00000000
    
22. r14: 0x00000000:00000000 r15: 0x00000000:00000000
    
23. rip: 0xffff8000:004000cd
    
24. eflags 0x00000246: id vip vif ac vm rf nt IOPL=0 of df IF tf sf ZF af PF cf
    
25. (0) [0x1f4000cd] 0058:ffff8000004000cd (unk. ctxt): mov ebx, 0x80000000 ; c7c300000080
    
26. <bochs:7> s
    
27. Next at t=177905196
    
28. rax: 0x00000000:80000000 rcx: 0x00000000:00000000
    
29. rdx: 0x00000000:00000000 rbx: 0x00000000:80000000
    
30. rsp: 0xfffff000:fffffff0 rbp: 0x00000000:0000b028
    
31. rsi: 0x00000000:ffff9000 rdi: 0x00000000:000b9900
    
32. r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
    
33. r10: 0x0000ee00:00000000 r11: 0xffff9000:00051008
    
34. r12: 0x00000000:00000000 r13: 0x00000000:00000000
    
35. r14: 0x00000000:00000000 r15: 0x00000000:00000000
    
36. rip: 0xffff8000:004000d3
    
37. eflags 0x00000246: id vip vif ac vm rf nt IOPL=0 of df IF tf sf ZF af PF cf

复制代码

我分别用两种指令编码方式来测试  mov reg32, imm32 ，结果都是将高32位清 0 了，它们都作了 “零扩展”动作

AMD /Intel　的文档都没说出这个问题。

mik

mov eax, 0x80000000 --> b8 00 00 00 80

mov ebx, 0x80000000 --> c7 c3 00 00 00 80

-------------------------------------------------------------------

两种编码方式都做了"零扩展"

以前还真没认识到这个问题，要记录下来。

qtdszws

AMD 第一卷上有

In general, byte and word operands are stored in the low 8 or 16
bits of GPRs without modifying their high 56 or 48 bits,
respectively. Doubleword operands, however, are normally
stored in the low 32 bits of GPRs and zero-extended to 64 bits.