hand, non-breaking breakpoints, sometimes called logpoints, can show the full state of a piece of code at the breakpoint without stopping its execution. Breakpoints can also be used to interrupt execution at a particular time, upon a keystroke etc. Inspection tools When a breakpoint is hit, various tools are used to inspect the state of the program or alter it. Stack trace of each thread may be used to see the chain of function calls that led to the paused instruction. A list of watches allows one to view the values of selected variables and expressions. There may also be tools to show the contents of registers, loaded program modules and other information. Implementations 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 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