Debugger
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
Part of a series on |
Software development |
---|
A debugger or debugging tool is a computer program used to test and debug other programs (the "target" program). The main use of a debugger is to run the target program under controlled conditions that permit the programmer to track its execution and monitor changes in computer resources that may indicate malfunctioning code. Typical debugging facilities include the ability to run or halt the target program at specific points, display the contents of memory, CPU registers or storage devices (such as disk drives), and modify memory or register contents in order to enter selected test data that might be a cause of faulty program execution.
The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered, but which will typically be somewhat slower than executing the code directly on the appropriate (or the same) processor. Some debuggers offer two modes of operation, full or partial simulation, to limit this impact.
A "
Features
Typically, debuggers offer a query processor, a symbol resolver, an expression interpreter, and a debug support interface at its top level.
The same functionality which makes a debugger useful for correcting bugs allows it to be used as a software cracking tool to evade copy protection, digital rights management, and other software protection features. It often also makes it useful as a general verification tool, fault coverage, and performance analyzer, especially if instruction path lengths are shown.[3] Early microcomputers with disk-based storage often benefitted from the ability to diagnose and recover corrupted directory or registry data records, to "undelete" files marked as deleted, or to crack file password protection.
Most mainstream debugging engines, such as
Record and replay debugging
Record and replay debugging,[4] also known as "software flight recording" or "program execution recording", captures application state changes and stores them to disk as each instruction in a program executes. The recording can then be replayed over and over, and interactively debugged to diagnose and resolve defects. Record and replay debugging is very useful for remote debugging and for resolving intermittent, non-deterministic, and other hard-to-reproduce defects.
Reverse debugging
Some debuggers include a feature called "reverse debugging", also known as "historical debugging" or "backwards debugging". These debuggers make it possible to step a program's execution backwards in time. Various debuggers include this feature.
Time Travel debugging
In addition to the features of reverse debuggers, time travel debugging also allow users to interact with the program, changing the history if desired, and watch how the program responds.
Language dependency
Some debuggers operate on a single specific language while others can handle multiple languages transparently. For example, if the main target program is written in
Memory protection
Some debuggers also incorporate memory protection to avoid storage violations such as buffer overflow. This may be extremely important in transaction processing environments where memory is dynamically allocated from memory 'pools' on a task by task basis.
Hardware support for debugging
Most modern microprocessors have at least one of these features in their
- Hardware support for single-stepping a program, such as the trap flag.
- An instruction set that meets the Popek and Goldberg virtualization requirements makes it easier to write debugger software that runs on the same CPU as the software being debugged; such a CPU can execute the inner loops of the program under test at full speed, and still remain under debugger control.
- In-system programming allows an external hardware debugger to reprogram a system under test (for example, adding or removing instruction breakpoints). Many systems with such ISP support also have other hardware debug support.
- Hardware support for code and data breakpoints, such as address comparators and data value comparators or, with considerably more work involved, page fault hardware.[6]
- ARM architecture processors or using the Nexuscommand set. Processors used in embedded systems typically have extensive JTAG debug support.
- Micro controllers with as few as six pins need to use low pin-count substitutes for JTAG, such as Atmel AVR. DebugWIRE, for example, uses bidirectional signaling on the RESET pin.
Debugger front-ends
Some of the most capable and popular debuggers implement only a simple command line interface (CLI)—often to maximize portability and minimize resource consumption. Developers typically consider debugging via a graphical user interface (GUI) easier and more productive.[citation needed] This is the reason for visual front-ends, that allow users to monitor and control subservient CLI-only debuggers via graphical user interface. Some GUI debugger front-ends are designed to be compatible with a variety of CLI-only debuggers, while others are targeted at one specific debugger.
List of debuggers
Some widely used debuggers are:
- Arm DTT, formerly known as Allinea DDT
- Eclipse debugger API used in a range of IDEs: Eclipse IDE (Java), Nodeclipse (JavaScript)
- Firefox JavaScript debugger
- GDB - the GNU debugger
- LLDB
- Microsoft Visual Studio Debugger
- Radare2
- Valgrind
- WinDbg
Earlier minicomputer debuggers include:
- Dynamic debugging technique (DDT)
- On-line Debugging Tool (ODT)
See also
References
Citations
- ^ Aggarwal and Kumar, p. 302.
- ^ Aggarwal and Kumar 2003, p. 301.
- ^ Aggarwal and Kumar, pp. 307-312.
- arXiv:1705.05937 [cs.PL].
- ^ Philip Claßen; Undo Software. "Why is reverse debugging rarely used?". Programmers Stack Exchange. Stack Exchange, Inc. Retrieved 12 April 2015.
- ^ Aggarwal and Kumar 2003, pp. 299-301.
Sources
- Sanjeev Kumar Aggarwal; M. Sarath Kumar (2003). "Debuggers for Programming Languages". In Y.N. Srikant; Priti Shankar (eds.). The Compiler Design Handbook: Optimizations and Machine Code Generation. Boca Raton, Florida: ISBN 978-0-8493-1240-3.
- Jonathan B. Rosenberg (1996). How Debuggers Work: Algorithms, Data Structures, and Architecture. ISBN 0-471-14966-7.
External links
- Debugging Tools for Windows
- OpenRCE: Various Debugger Resources and Plug-ins
- IntelliTrace MSDN, Visual Studio 2015