5

我的初学者书籍“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
4

1 回答 1

5

Your debugger is broken, or possibly the debug info created by NASM is broken. (Maybe try omitting the -g -F stabs from NASM. You can just use disassembly view anyway to debug asm, instead of source lines.)

Debuggers set breakpoints by rewriting the first byte of an instruction with a 0xcc byte (and int3 instruction). But apparently this is happening to the last byte of the mov instruction (high byte of the little-endian immediate in mov r32, imm32).

(Single-stepping uses a different mechanism from breakpoints; under Linux the ptrace system call which debuggers use has special support for single-stepping without having to create and remove a breakpoint on each instruction.)

Apparently hasn't been updated since 2009, so it's unlikely to get fixed. Don't use broken tools. But the tag popup says it's just a GDB front-end so IDK how it could introduce a low-level bug like this.

于 2019-09-18T05:15:50.503 回答