Unlike on a desktop where GDB launches and controls a process directly, on embedded GDB connects over a network socket to a gdbserver that bridges to the chip's hardware debug interface. Typically you run OpenOCD (or a vendor probe's server) configured for your debug adapter and target, which exposes the GDB remote protocol on a port (commonly :3333) and drives the MCU over JTAG or SWD. Then you launch the cross GDB (arm-none-eabi-gdb firmware.elf) and issue target remote :3333 to connect, optionally monitor reset halt (the monitor prefix forwards commands to OpenOCD) to reset and halt the core, load to program the ELF into flash, and then debug normally with breakpoints, stepping, and inspection. So the chain is GDB ↔ (GDB remote protocol over TCP) ↔ OpenOCD/gdbserver ↔ (JTAG/SWD) ↔ MCU. The practical implications: you must start the server first and connect to the right port; you flash via load rather than a separate tool when convenient; the debug probe provides hardware breakpoints and the ability to halt/reset the core; and you use monitor for adapter-specific actions. Forgetting the server or pointing at the wrong port is the usual reason "GDB won't connect" on embedded.
Debugging & Toolchain · Interview question
How does GDB connect to and debug an embedded target?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Debugging with GDB
Pause, inspect, and step through a running program: GDB's core commands (break/continue/step, print, backtrace), connecting to an embedded target over a gdbserver, and the optimization gotcha.