Using GDB to Debug Executables Without Debug Information

Introduction

MiHoYo, a Chinese game development company, shares a second‑round interview question: how to use GDB to debug an executable without debug information.

Problem Statement

Question: How to use GDB to debug an executable that does not contain debugging symbols?

Approach: Although symbol names are unavailable, basic debugging is still possible. Install GDB, start it with the target program, and use commands such as break (by address or offset), run , next , step , and print to inspect memory and registers.

Steps and Examples

Compile with -g to generate debug information (optional for comparison): gcc -g -o program program.c

Start GDB: gdb program

Set breakpoints, run, and step through the program: (gdb) break 10 (gdb) run (gdb) step (gdb) print variable_name

What is GDB?

GDB (GNU Debugger) supports languages such as C, C++, Ada, Objective‑C, and Pascal, and works for both local and remote debugging on Linux and Windows.

Installation and Startup

Check installation with gdb -v and install if missing.

Start GDB with gdb program or gdb then file program .

Pass arguments using gdb --args program arg1 arg2 or set them inside GDB with set args .

Core File Debugging

When a program crashes, a core file may be generated (requires ulimit -c unlimited ). Use gdb program core and the bt command to view the stack trace.

Common GDB Commands

list – show source lines.

break – set a breakpoint (by line, function, or address).

run – start the program.

next – step over a line.

step – step into a function.

continue – resume execution.

print – display variable or expression.

watch – stop when a variable changes.

catch – stop on events such as signals or library loads.

handle – configure signal handling.

info registers , info frame , backtrace – inspect registers, stack frames, and call stack.

Reverse Debugging (GDB 7.0+)

Record execution with record , then use reverse‑continue ( rc ) or reverse‑step ( rstep ) to move backward through the program flow, useful for tracing the origin of bugs.

Practical Example: VSCode + GDB + QEMU for ARM64 Kernel Debugging

This section describes building a minimal root filesystem with BusyBox, configuring an ARM64 Linux kernel (enabling CONFIG_DEBUG_INFO and CONFIG_INITRAMFS_SOURCE ), and launching QEMU with GDB remote debugging.

Install cross‑compilation tools (gcc‑aarch64‑linux‑gnu, etc.).

Build BusyBox statically and create an initramfs with required /etc files ( profile , inittab , fstab , and startup scripts).

Copy necessary libraries into the rootfs.

Configure the kernel (enable debug info, set initramfs source, etc.) and compile with make ARCH=arm64 Image .

Compile QEMU 4.2.1 from source and launch the kernel: /usr/local/bin/qemu-system-aarch64 -m 512M -smp 4 -cpu cortex-a57 -machine virt \ -kernel path/to/Image -append "rdinit=/linuxrc nokaslr console=ttyAMA0" \ -nographic -s The -s option opens GDB on port 1234.

Create a VSCode .vscode/launch.json configuration using gdb-multiarch and miDebuggerServerAddress: "localhost:1234" to attach to the running kernel.

Set breakpoints in the kernel source (e.g., init/main.c ) and perform step‑by‑step debugging directly from VSCode.

These steps demonstrate a complete workflow for low‑level debugging without symbol information, from simple user‑space programs to full kernel development.