Hardware 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 Without hardware support (and in multitasking environments),
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 (e.g. a
system call, or
int3 in case of
x86) or • an invalid instruction that causes a deliberate program interrupt (that is then intercepted/handled by the debugger) This technique may be more difficult to implement in multitasking systems using shared program storage (the interrupt may occur on a different thread, requiring resurrection of the original instruction for that thread). Also, if the program resides in protected memory, overwriting of instructions may be prevented. 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). •
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 invokes an internal or external debug subroutine, is yet another common approach. This method increases the
binary size and might adversely affect normal memory allocation and
exception handlers. "Debug" options exist on some compilers to implement this technique semi-transparently. Some debuggers allow registers or 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 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. Manually changing the resume location within a paused program can be used to enter an otherwise rarely executed section of code (such as a specific hardware condition handler). 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. 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 implementation 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. These facilities can be and are abused to act like the
COMEFROM statement. ==See also==