Search code examples
assemblyx86gdbinsight

Why does register eax show up as 0xccffffff in debugger after executing mov eax,0FFFFFFFFh

Instructions from my beginners book "Assembly Language Step-by-Step" has line: mov eax,0FFFFFFFFh. After freshly loading the program into the debugger 'Insight' the value of eax starts out as 0x0, but after line mov eax, 0FFFFFFFFh eax becomes instead 0xccffffff as said by the Registers window in Insight.

As a test I tried mov eax,02Dh and it became 0xcc00002d.

I researched 0xcc and found information on INT3: https://en.wikipedia.org/wiki/INT_(x86_instruction)#INT3 where my limits of understand are reached. All I understand is the opcode for INT3 is 0xCC and it's related to debugging. I am debugging but that would be rude to the first two 0xFFH of 0xFFFFFFFF and therefore I'd sure hope that NASM would have not allowed such.

Not sure if it's because I'm running x86-64 or something specific to my processor. My OS is 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

makefile

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

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

Expected Result

Following this book, the book's display of eax and ebx have these after executing said code:

eax     0xffffffff
ebx     0x2d

Actual Result

eax     0xccffffff
ebx     0x2d
Solution

  • 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.