【问题标题】：Why does register eax show up as 0xccffffff in debugger after executing mov eax,0FFFFFFFFh为什么在执行 mov eax,0FFFFFFFFh 后，寄存器 eax 在调试器中显示为 0xccffffff
【发布时间】：2020-01-18 23:25:17
【问题描述】：

我的初学者书籍“Assembly Language Step-by-Step”中的说明有线路：mov eax,0FFFFFFFFh。在将程序新加载到调试器 'Insight' 后，eax 的值开始为 0x0，但在行 mov eax, 0FFFFFFFFh eax 之后变为0xccffffff 如 Insight 中的 Registers 窗口所述。

作为测试，我尝试了mov eax,02Dh，它变成了 0xcc00002d。

我研究了0xcc，发现了关于INT3的信息： https://en.wikipedia.org/wiki/INT_(x86_instruction)#INT3 达到了我的理解极限。我所了解的是 INT3 的操作码是 0xCC ，它与调试有关。我正在调试，但这对 0xFFFFFFFF 的前两个 0xFFH 是不礼貌的，因此我当然希望 NASM 不会允许这样。

不确定是因为我运行的是 x86-64 还是特定于我的处理器的东西。我的操作系统是 Linux。

沙盒.asm

section .data
section .text

  global _start

_start:
    nop

    mov eax,0FFFFFFFFh
    mov ebx,02Dh
    ; !Reader - Important!
    ; !Examining values from this point! 

    ; Not reading values past this point
    dec ebx
    inc eax

    nop

section .bss

制作文件

sandbox: sandbox.o
    ld -o sandbox sandbox.o -melf_i386

sandbox.o: sandbox.asm
    nasm -f elf -g -F stabs sandbox.asm

预期结果

按照这本书，执行上述代码后，书中的eax和ebx显示有这些：

eax     0xffffffff
ebx     0x2d

实际结果

eax     0xccffffff
ebx     0x2d

【问题讨论】：

标签： assembly x86 gdb insight

【解决方案1】：

您的调试器已损坏，或者 NASM 创建的调试信息可能已损坏。（也许可以尝试从 NASM 中省略 -g -F stabs。无论如何，您都可以使用反汇编视图来调试 asm，而不是源代码行。）

调试器通过用0xcc 字节（和 int3 指令）重写指令的第一个字节来设置断点。但显然这发生在mov 指令的最后一个字节（mov r32, imm32 中小端立即数的高字节）。

（单步执行与断点使用不同的机制；在 Linux 下，调试器使用的ptrace 系统调用对单步执行具有特殊支持，而无需在每条指令上创建和删除断点。）

显然insight 自 2009 年以来就没有更新过，所以它不太可能得到修复。不要使用破损的工具。但是标签弹出窗口说它只是一个 GDB 前端，所以 IDK 怎么会引入这样的低级错误。

【讨论】：