When do you use logging versus a debugger like GDB?

They're complementary, suited to different bug classes. A debugger like GDB excels at inspecting deep state at a specific moment, you halt at a breakpoint and examine any variable, memory, register, or the call stack, so it's the tool for "what exactly is wrong here," like a crash you can backtrace or a corrupted structure you can dissect. But halting stops the world and perturbs timing, so it's poor for bugs that are about sequence and timing: races between tasks and interrupts, real-time deadline misses, intermittent protocol issues, or anything that changes when you stop the CPU (the Heisenbug problem). Logging is the opposite: it observes the flow of execution over time without stopping the program (especially with a fast, non-halting transport like RTT), so it's the right tool for timing/concurrency bugs, for capturing what led up to a rare failure, and for field diagnosis where you can't attach a debugger at all, at the cost of only seeing what you chose to log and adding some (ideally small, deferred) overhead. In practice you use both: logging to narrow down when and in what sequence something goes wrong and to monitor real-time behavior, and GDB to stop at the suspect point and examine the exact state. The decision heuristic is: state-at-a-moment → debugger; flow-and-timing-over-time, or no-halting-allowed → logging.