Stepping (debugging)

Program animation or stepping refers to the debugging method of executing code one instruction or line at a time. The programmer may examine the state of the program, machine, and related data before and after execution of a particular line of code. This allows the programmer to evaluate the effects of each statement or instruction in isolation, and thereby gain insight into the behavior (or misbehavior) of the executing program. Nearly all modern IDEs and debuggers support this mode of execution.

History

**System/360** (Model 65) operator's console, with register value lamps and toggle switches and buttons (middle of picture).

Instruction stepping or single cycle originally referred to the technique of stopping the processor clock and manually advancing it one cycle at a time. For this to be possible, three things are required:

A control that allows the clock to be stopped (e.g. a "Stop" button).
A second control that allows the stopped clock to be manually advanced by one cycle (e.g. An "instruction step" switch and a "Start" button).
Some means of recording the state of the processor after each cycle (e.g. register and memory displays).

On the IBM System 360 processor range announced in 1964, these facilities were provided by front panel switches, buttons and banks of neon lights. Other systems, such as the PDP-11, provided similar facilities.

On newer processors, which may not support physically stopping the clock and have too much internal state to reasonably display on a panel, similar functionality may be provided via a trap flag, which when enabled instructs the processor to stop after each instruction in a similar manner to a breakpoint.

As multiprocessing became more commonplace, such techniques would have limited practicality, since many independent processes would be stopped simultaneously. This led to the development of proprietary software from several independent vendors that provided similar features but deliberately restricted breakpoints and instruction stepping to particular application programs in particular address spaces and threads. The program state (as applicable to the chosen application/thread) was saved for examination at each step and restored before resumption, giving the impression of a single user environment. This is normally sufficient for diagnosing problems at the application layer.

Instead of using a physical stop button to suspend execution - to then begin stepping through the application program, a breakpoint or "Pause" request must usually be set beforehand, usually at a particular statement/instruction in the program (chosen beforehand or alternatively, by default, at the first instruction).

To provide for full screen "animation" of a program, a suitable I/O device such as a video monitor is normally required that can display a reasonable section of the code (e.g. in dis-assembled machine code or source code format) and provide a pointer (e.g. <==) to the current instruction or line of source code. For this reason, the widespread use of these full screen animators in the mainframe world had to await the arrival of transaction processing systems - such as CICS in the early 1970s and were initially limited to debugging application programs operating within that environment. Later versions of the same products provided cross region monitoring/debugging of batch programs and other operating systems and platforms.

With the much later introduction of Personal computers from around 1980 onwards, integrated debuggers were able to be incorporated more widely into this single user domain and provided similar animation by splitting the user screen and adding a debugging "console" to provide programmer interaction.

Borland Turbo Debugger was a stand-alone product introduced in 1989 that provided full-screen program animation for PC's. Later versions added support for combining the animation with actual source lines extracted at compilation time.

Techniques for program animation

There are at least three distinct software techniques for creating 'animation' during a program's execution.

Instrumentation involves adding additional source code to the program at compile time to call the animator before or after each statement to halt normal execution. This functionality may be part of the runtime library, as in Python's pdb module, or it may take the form of inserting a breakpoint instruction that triggers an external debugger if one is attached.
Induced interrupt This technique involves forcing a breakpoint at certain points in a program at execution time, usually by altering the machine code instruction at that point (this might be an inserted system call or deliberate invalid operation) and waiting for an interrupt. When the interrupt occurs, it is handled by the testing tool to report the status back to the programmer. This method allows program execution at full speed (until the interrupt occurs) but suffers from the disadvantage that most of the instructions leading up to the interrupt are not monitored by the tool.
Instruction set simulator This technique treats the compiled program's machine code as its input 'data' and fully simulates the host machine instructions, monitors the code for conditional or unconditional breakpoints or programmer requested "single cycle" animation requests between every step.

Comparison of methods

The advantage of the last method is that no changes are made to the compiled program to provide the diagnostic and there is almost unlimited scope for extensive diagnostics since the tool can augment the host system diagnostics with additional software tracing features. It is also possible to diagnose (and prevent) many program errors automatically using this technique, including storage violations and buffer overflows. Loop detection is also possible using automatic instruction trace together with instruction count thresholds (e.g. pause after 10,000 instructions; display last n instructions) The second method only alters the instruction that will halt before it is executed and may also then restore it before optional resumption by the programmer. Some animators optionally allow the use of more than one method depending on requirements. For example, using method 2 to execute to a particular point at full speed and then using instruction set simulation thereafter.

Additional features

The animator may, or may not, combine other test/debugging features within it such as program trace, dump, conditional breakpoint and memory alteration, program flow alteration, code coverage analysis, "hot spot" detection, loop detection or similar.

References

External links