为何mov %ax,%ds编译反汇编后变为mov %eax,%ds？

问题重现 #

原始汇编代码：

.text
.global _start
_start:
    xor %ax, %ax
    mov %ax, %ds
    mov %ax, %ss
    mov %ax, %es
    mov %ax, %fs
    mov %ax, %gs

编译及反汇编命令：

x86_64-elf-gcc -g -c -O0 -m32 -fno-pie -fno-stack-protector -fno-asynchronous-unwind-tables ./test.S
x86_64-elf-ld ./test.o -m elf_i386  -Ttext=0x7c00 -o test.elf
x86_64-elf-objdump -x -d -S -m i386 ./test.elf > test_dis.txt

核心原因 #

这是x86架构32位模式下的指令编码规则导致的：

• 在32位保护模式下，将通用寄存器写入段寄存器的指令，机器码统一使用32位寄存器的编码格式，没有单独的16位寄存器到段寄存器的编码。
• 你编写的mov %ax, %ds，汇编器在32位编译环境下会将其转换为对应32位寄存器eax的机器码（比如机器码8E D8）——因为x86架构规定，这类指令在32位模式下只能用32位寄存器标识。
• 反汇编工具objdump是根据机器码来解析指令的，它看到的是32位寄存器的编码，所以会显示为mov %eax, %ds。但CPU执行该指令时，只会取eax的低16位（也就是ax的值）写入段寄存器，实际执行效果和你编写的mov %ax, %ds完全一致。

额外说明 #

如果希望反汇编结果显示为16位寄存器的写法，需要切换到16位实模式的代码生成：

• 在汇编代码开头添加.code16指定16位模式
• 编译时调整参数（比如使用NASM而非GAS，配合-f bin格式），但这会改变代码的运行模式，和当前32位编译的场景不同。

内容的提问来源于stack exchange，提问作者Markity