X86-64汇编中整数溢出处理及32位寄存器值异常问询

一、8位整数运算后AL寄存器值异常的原因及汇编溢出防护 #

问题场景 #

测试以下汇编代码后，通过GDB调试发现add指令执行后，info registers rax显示305符合预期，但info registers al显示49：

section .text
    global _start
section .int_8 write
    int_8 db 5
section .text
    _start:
        mov al, [int_8]
        push 300
        pop rbx
        add rax, rbx

解答 #

• 这确实是8位无符号整数的溢出环绕。AL是8位寄存器，仅能存储0~255的数值，305减去2^8（256）后得到49，这是CPU对无符号整数溢出的默认处理逻辑——直接丢弃高位，仅保留低8位。
• 汇编层面无法让CPU自动触发溢出警告，必须手动实现运行时溢出检测逻辑：
  NASM仅在编译阶段检查db/dw/dd/dq这类伪指令的立即数溢出（比如num_1 db 300会报错），但运行时运算溢出不会主动拦截。要保证代码安全，需利用CPU的标志位判断：
  • 无符号运算：检查add指令后的CF（进位标志位），若CF=1则说明无符号溢出。
  • 有符号运算：检查add指令后的OF（溢出标志位），若OF=1则说明有符号溢出。
    更高效的8位无符号加法溢出检查示例：

  ; 假设al存储第一个操作数，bl存储第二个操作数
  add al, bl
  jc overflow_handler  ; CF置位则跳转到溢出处理
  ; 正常执行逻辑
  overflow_handler:
      mov rax, 60
      mov rdi, 8
      syscall
  

二、32位整数加载后RAX与EAX显示差异及正确的32位溢出检查 #

问题场景 #

将声明为dd的4294967290加载到RAX后，info registers rax显示数值正确，但info registers eax显示负数，原检查逻辑（判断eax是否大于0）不合理。

解答 #

• RAX与EAX显示差异的原因：
  EAX是RAX的低32位，GDB默认以有符号十进制显示32位寄存器。4294967290的十六进制为0xFFFFFFFA，作为32位有符号数时最高位为1，会被解释为负数（-6）；而RAX是64位寄存器，加载32位值时高32位会被自动清零，因此64位视角下是无符号的4294967290，显示正常。
• 正确的32位溢出检查逻辑：
  分两种场景处理：
  1. 无符号32位运算：例如执行add eax, ebx后，检查CF标志位——CF=1代表结果超出无符号32位范围（0~2^32-1）。
  2. 有符号32位运算：同样执行add eax, ebx后，检查OF标志位——OF=1代表结果超出有符号32位范围（-2^31~231-1）。
     若使用64位寄存器处理32位值，需先确保高32位被清零（比如用mov eax, [int_32]而非mov rax, [int_32]），再进行32位运算并检查标志位，避免64位运算掩盖溢出情况。

补充：原8位溢出检查代码的优化说明 #

你之前实现的8位溢出检查代码：

pop rcx ;; Get return address
 pop rax
 movzx rbx, al ;; Move 8 bits into the rbx registery
 cmp rax, rbx
 je no_overflow_int_8
 jne has_overflow_int_8
 no_overflow_int_8:
 push rcx
 ret
 has_overflow_int_8:
 mov rax, 60
 mov rdi, 8
 syscall

这种方式通过比较RAX和零扩展后的RBX判断溢出，虽然可行，但效率不如直接利用CPU的CF/OF标志位——标志位是运算指令自动设置的，无需额外的寄存器操作和比较指令。

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