Mastering Debugging in C with GDB: From Live Debugging to Core Dump Analysis

Debugging is one of the most important skills for a systems programmer. Whether your program crashes unexpectedly or behaves incorrectly, GDB (GNU Debugger) gives you deep visibility into what your program is doing at runtime — down to registers and assembly instructions.

In this article, we’ll cover both live debugging and core dump debugging, and how to use GDB effectively in real-world scenarios.

🔧 1. Preparing Your Program for Debugging

Compile with debug symbols

Always compile your program with the -g flag:

gcc -g program.c -o program

This embeds debugging information such as:

• Source file names
• Line numbers
• Variable names
• Function names

Without -g, GDB can still run, but debugging will be painful and limited.

🧠 2. Debugging a Program Using GDB (Live Debugging)

Start GDB

gdb ./program

Inside GDB, your program is not running yet.

Set a breakpoint

Breakpoints stop execution at specific locations.

break main

You can also break at:

break function_name
break file.c:42

Then start the program:

run

Stepping Through Code

Once execution stops:

If GDB pauses output, press Enter to continue.

🧩 3. Viewing Source, Assembly, and Registers

GDB allows mixed-level debugging.

Source and Assembly Views

layout src      # C source
layout asm      # Assembly
layout regs     # CPU registers

Switch layouts with:

layout next

Inspecting Instructions

x/i $pc

• x → examine memory
• /i → instruction format
• $pc → program counter (current instruction)

To see more instructions:

x/10i $pc

🧠 4. Understanding CPU Registers (Critical Skill)

To view all registers:

info registers

Important x86-64 Registers

Example: Segmentation Fault Analysis

If your program crashes and you see:

rip = 0x0

It usually means: 👉 You jumped to a NULL pointer.

If rsp or rbp looks corrupted: 👉 Stack overflow or memory corruption likely occurred earlier.

🧨 5. Debugging with Core Dumps (Post-Crash Debugging)

Core dumps allow you to analyze a crash after the program has already terminated.

Enable core dumps

ulimit -c unlimited

Set core file pattern (optional)

echo "core" | sudo tee /proc/sys/kernel/core_pattern

This creates a file named core in the working directory.

When is a core file generated?

Only when the program terminates due to fatal signals such as:

• SIGSEGV (segmentation fault)
• SIGABRT
• SIGFPE
• SIGILL

Normal exits or Ctrl+C do not generate core dumps.

Debugging a core file

gdb ./program core

Then use:

bt              # backtrace
info registers  # CPU state at crash
x/i $pc         # instruction that crashed

This allows you to debug crashes after the fact, even on production systems.

🧩 6. Typical Debugging Workflow

1. Program crashes
2. Load core file into GDB
3. Inspect backtrace (bt), or use up to go back step by step
4. Check registers and instruction pointer
5. Identify corrupted data or invalid memory access
6. Fix code and recompile

🧠 7. Pro Tips

• Use -O0 during debugging (disable optimization)

• Combine with sanitizers:

  gcc -g -fsanitize=address -O0 program.c

• Learn to read assembly — it greatly improves debugging skills

• Core dumps are essential for production debugging