Breakpoint

During the interruption, the programmer inspects the test environment (general-purpose registers, memory, logs, files, etc.)

Programmers have used machine code patches to implement single destructive breakpoints to cause a core dump since the early days of computers.

The core dump provided the state of the registers and memory at the exact moment of the deliberate "crash".

Such hardware may include limitations, for example not allowing breakpoints on instructions located in branch delay slots.

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.

[5] 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.