A breakpoint is an instruction to a debugger to stop a program when execution reaches a particular place in the code. As the GDB manual’s chapter on breakpoints explains, the programmer specifies the place where the program should stop by line number, function name, or exact address, and may attach a condition so that the stop happens only when some expression is true. When the program reaches that point, the debugger suspends it and hands control back to the developer, who can then inspect the call stack, examine variables and memory, and decide whether to step, continue, or change something.
Closely related is the watchpoint, which the GDB manual describes as a special breakpoint that stops the program when the value of an expression changes. Rather than triggering at a fixed location, a watchpoint fires wherever in the program a particular variable or memory location is written with a new value. This makes watchpoints the natural tool for answering the question of where, exactly, some piece of data is being corrupted. The manual also documents catchpoints, which stop on events such as exceptions or system calls.
Breakpoints come in two implementation flavors. A software breakpoint works by temporarily replacing the instruction at the target address with a special trap instruction; on the common x86 architecture this is the single-byte INT 3 instruction, opcode 0xCC, whose entire reason for existing is to raise a debug trap. When the processor executes the trap it interrupts the program and transfers control to the operating system, which signals the debugger. The debugger then restores the original instruction, lets the developer work, and re-inserts the trap when execution continues. Because software breakpoints rewrite code in memory, a program can have effectively unlimited numbers of them.
A hardware breakpoint, by contrast, uses dedicated debug registers built into the processor. The developer loads a target address into one of these registers, and the CPU itself raises a debug exception when execution or, for hardware watchpoints, a data access touches that address. Hardware support is what makes efficient watchpoints practical: instead of single-stepping the whole program and checking a value after every instruction, the processor monitors the memory location at full speed and traps only when it is accessed. The trade-off is that the number of hardware breakpoints and watchpoints is small, limited by the handful of debug registers the architecture provides.
Underneath both kinds, the debugger relies on the operating system’s process-tracing facilities to insert traps, catch the resulting signals, and read back the stopped program’s state. On Linux this is the ptrace system call, whose manual page notes that it is primarily used to implement breakpoint debugging and system call tracing. The breakpoint, simple as it sounds, is therefore the meeting point of compiler-emitted debug information, processor trap mechanisms, and operating-system tracing services.