GDB debugging — breakpoints, watchpoints, step, next, backtrace: Visual walkthrough

This is the visual companion to the GDB debugging note. We assume you know nothing but "a program is a list of instructions the CPU runs one after another."

Step 1 — What "running normally" even means

WHY we start here: before we can measure extra cost, we must measure the baseline — the time when GDB is doing nothing special. Every symbol in the final formula is a comparison against this baseline, so it must be pinned down first.

PICTURE: Look at the green bar below. It is one program run, chopped into $N$ equal slices — each slice is one source line of your code. The whole green bar takes total time $T_{0}$ .

Figure — GDB debugging — breakpoints, watchpoints, step, next, backtrace

So the cost of one line, on average, is the green bar's length divided into $N$ pieces: $T_{0} / N$ . Hold onto that number — it's tiny, and its tininess is the whole plot.

Step 2 — What a watchpoint is asking the CPU to do

WHY this matters: a breakpoint knows its address, so GDB pokes one trap byte and walks away (see Parent Step: byte substitution). A watchpoint can't do that — the variable might be modified by line 3, or line 300, or a line in a library. GDB is forced to check after every single line.

PICTURE: the red magnifying glass sits between every pair of green slices. That gap is the check GDB inserts. There are $N$ slices, so there are $N$ checks.

The red glass is not free. Each one costs a fixed amount of time. We give it a name in the next step.

Step 3 — Naming the cost of one check: $c$

WHY a single letter: the three sub-costs always happen together, once per line, so we don't need three symbols — we need one. Collapsing them into $c$ keeps the algebra honest and the picture clean.

PICTURE: we zoom into a single red glass and unfold it into its trap → read → compare pieces. Their total width is labelled $c$ .

Step 4 — Adding up all the extra work

WHY multiply: this is the definition of "the same fixed cost, repeated." $N$ identical red glasses laid end to end have total length $N \times c$ . No calculus needed — repetition is multiplication.

PICTURE: the green baseline bar, now with a red bar of length $N c$ bolted onto its end. The red bar is the pile of all the traps.

Step 5 — Turning time into a slowdown ratio

WHY divide, not subtract: subtracting gives you seconds of delay ( $N c$ ), but a 100 s delay is trivial on a 3-hour job and catastrophic on a 1 s job. Dividing by $T_{0}$ makes the answer scale-free — it tells you the factor, which is what "10× slower" means in everyday speech.

PICTURE: we stack the red-plus-green bar on top of the plain green bar and read off how many times taller it is.

Step 6 — Plug in numbers (forecast → verify)

WHY these numbers: they're deliberately "normal" — a 1-second program running a hundred million lines — so the shocking answer isn't a trick of exotic inputs.

PICTURE: the same stacked bars, now with real tick values, so you see 100 s of red towering over 1 s of green.

Step 7 — The degenerate cases (never leave a gap)

Every honest derivation must survive its extreme inputs. Here are the four corners.

PICTURE: four mini-panels, one per corner case, each showing what the red bar does.

Case	What happens to $S = 1 + N c / T_{0}$	Meaning
$c \to 0$ (hardware watchpoint, panel A)	$S \to 1$	The debug register traps automatically on write — no per-line software check, so $c \approx 0$ . Watchpoint is invisible.
$N \to 0$ (program does nothing, panel B)	$S \to 1$	No lines run → no checks → no tax. Trivially, nothing is slower.
$N \to \infty$ (long loop, panel C)	$S \to \infty$	The longer the run, the more traps pile up. Slowdown is unbounded.
variable out of scope (panel D)	GDB deletes the watchpoint	Once the watched local dies, there's nothing to watch — the tax stops, but so does your observation.

The one-picture summary

Everything above, compressed: a green baseline of $N$ lines, a red trap glued to each line, the ratio that turns "seconds" into "times slower," and the two regimes (software = tall red, hardware = no red).

Recall Feynman: the whole walkthrough in plain words

Imagine your program is a runner sprinting a track once — that sprint takes time $T_{0}$ , and the track has $N$ steps. A software watchpoint is a referee who forces the runner to fully stop, get inspected, and restart after every single step. Each stop-and-inspect costs a fixed chunk of time $c$ . Since there are $N$ steps, the referee adds $N \times c$ of pure standing-around time. To feel how bad that is, compare the standing-around ( $N c$ ) to the actual running ( $T_{0}$ ): that ratio, plus $1$ for the run itself, is the slowdown $S$ . Because one inspection ( $c$ ) takes way longer than one running step ( $T_{0} / N$ ), the standing-around dwarfs the run, and a 1-second sprint balloons to 101 seconds. The fix is the hardware watchpoint: instead of a referee stopping the runner every step, the track itself rings a bell only when the watched spot is stepped on — almost no stopping, so $S$ drops back to $1$ . That's why GDB picks hardware watchpoints whenever the chip's four debug registers are free.

Recall Quick self-test

Software watchpoint on a program with $T_{0} = 2$ s, $N = 1 0^{9}$ , $c = 1 0^{- 6}$ s — what is $S$ ? ::: $S = 1 + (1 0^{9}) (1 0^{- 6}) /2 = 1 + 500 = 501 \times$ . Why does the leading $1$ in $S = 1 + N c / T_{0}$ mean you can never beat normal speed? ::: Because $N c / T_{0} \geq 0$ , so $S \geq 1$ always — the debugger only ever adds time, never removes it. A hardware watchpoint makes $S \approx 1$ . Which symbol did it drive to (almost) zero, and how? ::: It drove $c$ (really, the number of traps) to near zero by using a debug register that traps only on an actual write instead of checking every line.