debug-optimized-builds

Debugging Optimized Builds

Purpose

Guide agents through debugging code compiled with optimization: choosing the right debug-friendly optimization level, reading inlined frames, diagnosing "value optimized out", using split-DWARF for faster debug builds, and applying GDB techniques specific to optimized code.

Triggers

• "GDB says 'value optimized out' — what does that mean?"
• "How do I debug a release build?"
• "How do I see inlined function frames in GDB?"
• "What's the difference between -O0 and -Og for debugging?"
• "How do I use RelWithDebInfo with CMake?"
• "Breakpoints in optimized code land on wrong lines"

Workflow

1. Choose the right build configuration

Goal?
├── Full debuggability, no optimization
│   → -O0 -g                        (slowest, all vars visible)
├── Debuggable, some optimization (recommended for most dev work)
│   → -Og -g                        (-Og keeps debug experience good)
├── Release build with debug info (shipped, debuggable crashes)
│   → -O2 -g -gsplit-dwarf          (or -O2 -g1 for lighter info)
└── Full release (no debug symbols)
    → -O2 -DNDEBUG

-Og: GCC's "debug-friendly optimization" — enables optimizations that don't interfere with debugging. Variables stay in registers where GDB can see them. Line numbers stay accurate. Best balance for development.

# GCC / Clang
gcc -Og -g -Wall main.c -o prog

# CMake build types
cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug          # -O0 -g
cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo # -O2 -g -DNDEBUG
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release        # -O2 -DNDEBUG

2. "Value optimized out" — causes and workarounds

(gdb) print my_variable
$1 = <optimized out>

This means the compiler decided the variable's value doesn't need to be stored at this point — it might be:

• Kept only in a register (not the one GDB is looking at)
• Folded into a constant by constant propagation
• Eliminated because it's not used after this point
• Replaced by a later optimized value