(Programming, debugging:)
A breakpoint, when hit, transfers execution from the program to the debugger. A breakpoint is set on some address in the debugged program; the debugger arranges matters so that the program will stop just before executing the instruction at that address, and control will revert to the debugger.
Typically, the programmer running the debugger will use the time afforded by the breakpoint to examine the state of the program's data. It is, of course, entirely possible to use the various single stepping debugger commands to reach any point in the execution of the program. Given, however, that a program's execution trace can easily consist of hundreds of millions of instructions, the use of appropriately-chosen breakpoints is understandable.
Breakpoints are "soft" if managed entirely by the debugger (e.g. by overwriting code in the executable with an appropriate interrupt or TRAP instruction), or "hard" if some support from the CPU is given to the debugger. Either way, breakpoints are usually extremely efficient ways to stop the program in the debugger; on any reasonable CPU, the debugger does not have to single step the program, comparing the PC to the list of breakpoint addresses.
gdb provides these "must-have features" for its breakpoints:
- set breakpoint by line in source code or by address
- conditional breakpoints
- Stop execution only if some condition holds
- count # of times breakpoint hit
- This occurs automatically; it is chiefly useful in conjunction with the breakpoint's ``ignore count'', below.
- ignore count for breakpoints
- Ignore first N times the breakpoint is hit. To stop at iteration 100 of the loop, place a breakpoint at its first statement and ignore it the first 99 times. To stop the program just before a memory fault: First, instruct gdb to ignore a well-situated breakpoint 99999999 times (or some other huge number) and run the program. After the program faults, examine the number of times the breakpoint was hit (info breakpoints). Now set the breakpoint's ignore count to one less, and run the program again.
- set breakpoint on exit from procedure
- Execution will stop, no matter which return statement (or throw, if using!) caused the procedure exit.
- execute commands on breakpoint
- Run any debugger command(s) after the program stops, before returning control to the debugger's UI. This can also be used by graphical front-ends like ddd, but is useful for the end-user too.
- enable/disable breakpoints
- So you don't have to delete a breakpoint (and lose its location, condition, and commands!) just to lose its effect for a while.
- temporary breakpoints
- When hit, it deletes itself. (You could, of course, program this yourself by telling gdb to execute the appropriate command when the breakpoint is hit.)