为什么在执行 mov eax,0FFFFFFFFh 后寄存器 eax 在调试器中显示为 0xccffffff
Why does register eax show up as 0xccffffff in debugger after executing mov eax,0FFFFFFFFh
我的初学者书籍“Assembly Language Step-by-Step”中的说明有
行：mov eax,0FFFFFFFFh。将程序重新加载到调试器 'Insight' 后，eax 的值开始为 0x0，但在行 mov eax, 0FFFFFFFFh 之后eax 变为 0xccffffff，正如 Insight 中的寄存器 window 所说。
作为测试，我尝试了 mov eax,02Dh，它变成了 0xcc00002d。
我研究了 0xcc 并找到了关于 INT3 的信息：
https://en.wikipedia.org/wiki/INT_(x86_instruction)#INT3 达到了我的理解极限。我所了解的是 INT3 的操作码是 0xCC，它与调试有关。我正在调试，但这对 0xFFFFFFFF 的前两个 0xFFH 是不礼貌的，因此我希望 NASM 不会允许这样。
不确定是不是因为我是 运行 x86-64 或我的处理器特有的东西。我的 OS 是 Linux.
sandbox.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
您的调试器已损坏，或者 NASM 创建的调试信息可能已损坏。 （也许可以尝试从 NASM 中省略 -g -F stabs。你可以只使用反汇编视图来调试 asm，而不是源代码行。）
调试器通过用 0xcc 字节（和 int3 指令）重写指令的第一个字节来设置断点。但显然这发生在 mov 指令的最后一个字节（mov r32, imm32 中小端立即数的高字节）。
（单步执行使用与断点不同的机制；在 Linux 下，调试器使用的 ptrace 系统调用对单步执行有特殊支持，无需在每个断点上创建和删除断点说明。)
显然 insight 自 2009 年以来就没有更新过，因此不太可能得到修复。不要使用损坏的工具。但是标签弹出窗口说它只是一个 GDB 前端所以我想知道它怎么会引入这样的低级错误。
我的初学者书籍“Assembly Language Step-by-Step”中的说明有
行：mov eax,0FFFFFFFFh。将程序重新加载到调试器 'Insight' 后，eax 的值开始为 0x0，但在行 mov eax, 0FFFFFFFFh 之后eax 变为 0xccffffff，正如 Insight 中的寄存器 window 所说。
作为测试，我尝试了 mov eax,02Dh，它变成了 0xcc00002d。
我研究了 0xcc 并找到了关于 INT3 的信息： https://en.wikipedia.org/wiki/INT_(x86_instruction)#INT3 达到了我的理解极限。我所了解的是 INT3 的操作码是 0xCC，它与调试有关。我正在调试，但这对 0xFFFFFFFF 的前两个 0xFFH 是不礼貌的，因此我希望 NASM 不会允许这样。
不确定是不是因为我是 运行 x86-64 或我的处理器特有的东西。我的 OS 是 Linux.
sandbox.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
您的调试器已损坏，或者 NASM 创建的调试信息可能已损坏。 （也许可以尝试从 NASM 中省略 -g -F stabs。你可以只使用反汇编视图来调试 asm，而不是源代码行。）
调试器通过用 0xcc 字节（和 int3 指令）重写指令的第一个字节来设置断点。但显然这发生在 mov 指令的最后一个字节（mov r32, imm32 中小端立即数的高字节）。
（单步执行使用与断点不同的机制；在 Linux 下，调试器使用的 ptrace 系统调用对单步执行有特殊支持，无需在每个断点上创建和删除断点说明。)
显然 insight 自 2009 年以来就没有更新过，因此不太可能得到修复。不要使用损坏的工具。但是标签弹出窗口说它只是一个 GDB 前端所以我想知道它怎么会引入这样的低级错误。