QEMU can expose a GDB remote-debugging stub that lets GDB attach to code running inside the emulated machine—kernel, bootloader, firmware—and step through it as if it were a local process. The standard way to debug early boot without a JTAG probe.

qemu-system-arm -M versatilepb -kernel zImage -s -S -nographic

-s opens a GDB stub on localhost:1234; -S freezes the CPU at startup (waits for GDB to attach before running). In another terminal:

gdb zImage
(gdb) target remote localhost:1234
(gdb) continue
(gdb) break main
(gdb) continue

After target remote, GDB connects to QEMU. continue resumes the frozen CPU. Set breakpoints as usual—GDB will pause when they hit.

Omit -S to let the kernel boot while GDB is attaching:

qemu-system-arm -M versatilepb -kernel zImage -s -nographic
# Then quickly in another terminal:
gdb zImage
(gdb) target remote localhost:1234
(gdb) <breakpoint already hit or catch next>

This is useful when boot is fast and you want to start debugging mid-boot.

Without -s, QEMU runs normally (no GDB stub). The stub adds negligible overhead—you can run with -s all the time and attach GDB only when needed.

GDB debugging of kernels or bootloaders is more reliable than printk or serial-port debugging. You see the actual execution, register state, memory contents, and can inspect the call stack instantly. Invaluable for debugging hardware initialization or boot-time crashes.

Remote debugging over the network: -gdb tcp::1234 instead of -s (default localhost), then target remote host:1234 from GDB.