What can GDB do that printf debugging can't?

GDB gives you interactive control and complete visibility of a running program, whereas printf only shows what you anticipated logging. With GDB you can pause execution at any breakpoint, inspect any variable, memory location, CPU register, or expression at that moment, step through the code line by line (over or into calls), examine the full call stack to see how you got there, and even modify state live to test a hypothesis, all without recompiling. That's transformative for bugs you didn't predict: a crash you can backtrace to the exact function and line, a corrupted struct you can examine byte by byte, a wrong value you can trace by stepping. printf, by contrast, requires you to guess what to print and where, recompile and reflash to add prints, and it perturbs timing and code size; it can't show you the call stack or arbitrary memory after the fact. The flip side is that GDB halts the program (a Heisenbug risk for real-time/timing-dependent issues) and needs symbols and a debug connection, so the two are complementary, GDB for deep state inspection and post-mortem analysis, logging for observing real-time behavior without stopping. But for "what is the actual state right now and how did I get here," nothing matches a debugger.