What is a conditional breakpoint and what's the catch on embedded?

A conditional breakpoint only halts when an attached expression evaluates true, for example break process if id == 0x1000 stops only when that argument matches, or break loop.c:20 if i == 999 stops only on the iteration you care about. It's invaluable for "stop only in the bad case" when a location is hit thousands of times but only one occurrence is interesting, sparing you from manually continuing past all the irrelevant hits. The catch on embedded is how the condition is evaluated: unless the debug hardware can evaluate it (rare for arbitrary conditions), GDB implements the condition in software by setting an ordinary breakpoint, halting every time it's hit, reading the relevant variables over the debug link to evaluate the condition, and automatically resuming if it's false. For a breakpoint in a hot path that's hit very frequently, this halt-evaluate-resume cycle is extremely slow (each halt is a full debug-protocol round trip) and, because each halt stops the core, it heavily perturbs timing, so a timing-dependent bug may shift or vanish, and the program may run so slowly it becomes impractical. Mitigations: make conditions cheap and on infrequently-hit locations, or restructure the code to add a dedicated check you can breakpoint on, or use a watchpoint/trace instead. So conditional breakpoints are powerful for filtering, but on embedded their software evaluation makes them costly on hot paths in both speed and timing fidelity, which you weigh before using them in real-time-sensitive code.