When you set a watchpoint in GDB — "break when this variable changes" — the debugger isn't polling the address in a loop. It's programming a set of dedicated silicon registers that let the CPU fire an exception the moment matching memory activity happens, at full execution speed.

On x86, this is DR0 through DR7. Four address slots (DR0–DR3), a control register (DR7), and a status register (DR6). DR4/DR5 are reserved aliases. That's it — you get exactly four hardware watchpoints per core, a hard ceiling baked into the ISA since the 386.

Each of the four slots is programmed with:

• A linear address to monitor
• A length: 1, 2, 4, or 8 bytes (naturally aligned)
• A condition: instruction fetch, data write, data read-or-write, or I/O access

The magic is in the pipeline: every load/store address the AGU produces gets compared in parallel against all four DR registers by dedicated comparators. On a match, the CPU raises a #DB (debug exception), sets the corresponding bit in DR6, and the OS delivers SIGTRAP to your debugger. Zero software overhead when idle, zero polling, zero cache pollution.

Real-world example: Chasing memory corruption where some rogue write is stomping a struct field at offset 0x18. In GDB: watch *(int*)0x7ffff7a1c018. Under the hood, GDB writes the address into DR0, sets DR7 to enable slot 0 with length=4 and condition=write. Your program then runs at native speed for hours until the offending store executes — and GDB traps exactly on the instruction after the guilty write. Without hardware watchpoints, GDB would fall back to single-stepping and checking the value after every instruction: a 10,000× slowdown.

Rule of thumb: If you're watching ≤4 addresses of ≤8 bytes each, watchpoints cost essentially nothing. If you try to watch a 64-byte struct, GDB silently falls back to software watchpoints — and your program slows to a crawl. Always check: info watchpoints tells you which are "hw" vs "sw".

Gotchas: DR registers are per-CPU, but the OS virtualizes them per-thread on context switch. Ring-3 code can't touch them directly — you go through ptrace on Linux. And on SMT/hyperthreaded cores, the two logical threads share separate DR state (unlike most other CPU resources), which is why watchpoints work correctly across threaded debugging.

ARM has an analogous mechanism with more slots (typically 4–16 watchpoint units, ID-register discoverable) but the same core idea: comparators in the load/store pipeline, exception on match.