Breakpoint
A breakpoint, in software development, is an intentional stopping or pausing place in a program, put in place for debugging purposes. It is also sometimes simply referred to as a pause. More generally, a breakpoint is a means of acquiring knowledge about a program during its execution. During the interruption, the programmer inspects the test environment (general purpose registers, memory, logs, files, etc.) to find out whether the program is functioning as expected. In practice, a breakpoint consists of one or more conditions that determine when a program's execution should be interrupted.
The most common form of a breakpoint is one where the program's execution is interrupted before a programmer-specified instruction is executed. This is often referred to as an instruction breakpoint.
Other kinds of conditions can also be used, such as the reading, writing, or modification of a specific location in an area of memory. This is often referred to as a conditional breakpoint, a data breakpoint, or a watchpoint.
Breakpoints can also be used to interrupt execution at a particular time, or upon a keystroke etc.
Hardware implementation
Many processors include hardware support for breakpoints (typically instruction and data breakpoints). As an example, the x86 instruction set architecture provides hardware support for breakpoints with its x86 debug registers. Such hardware may include limitations, for example not allowing breakpoints on instructions located in branch delay slots. This kind of limitation is imposed by the microarchitecture of the processor and varies from processor to processor.
Software implementations
Without hardware support, debuggers have to implement breakpoints in software. For instruction breakpoints, this is a comparatively simple task of replacing the instruction at the location of the breakpoint by either:
- an instruction that calls the debugger directly (eg a system call) or
- an invalid instruction that causes a deliberate program interrupt (that is then intercepted/handled by the debugger)
Alternatively,
- an instruction set simulator can implement unconditional or conditional breakpoints, by simply embedding the appropriate condition tests within its own normal program cycle - that also naturally allows non-invasive breakpoints (on read-only programs for instance)[1].
- Interpreted languages can effectively use the same concept as above in their program cycle.
- "Instrumenting" all the source code with additional source statements that issue a function that invoke an internal or external debug subroutine, is yet another common approach. This method increases the binary size and might adversely effect normal memory allocation and exception handlers. "Debug" options exist on some compilers to implement this technique semi-transparently.
Some debuggers allow program variables in memory to be modified before resuming, effectively allowing the introduction of "hand-coded" temporary assignments for test purposes. Similarly, program instructions can often be skipped to determine the effect of changes to the program logic - enabling "What-if"" questions about program execution to be answered in a direct way (i.e. without assumptions or guesswork. In many cases it may be the only practical method of testing obscure "event-driven" error subroutines that rarely, if ever, get executed - without the added risk of leaving temporary source changes in situ.
Implementing data breakpoints in software however, can greatly reduce the performance of the application being debugged - since it is using additional resources on the same processor[2]. However, this is normally acceptable during testing and the amount of information available from the debugger is not restricted by limitations of debug data known to the hardware. For instance, a software impementation can collect logical path data at program/subroutine/instruction level to considerably augment what might be stored by the particular hardware platform for inspection. The instruction set simulation method considerably reduces the overhead compared to the (repeated) instruction replacement method, also reducing cache misses.
Some programming language implementations expose their debugging functions for use by other programs.
For example, some FORTRAN dialects have an AT statement, which was originally intended to act as an instruction breakpoint.
Python implements a debugger accessible from a Python program.[3]
These facilities can be and are[4] abused to act like the COMEFROM statement.