Debugger
A debugger (from English de- ( prefix ; dt. Ent- , aus- ) in the sense of remove and English bug in the sense of program error ) is a tool for diagnosing and finding errors in computer systems , especially in programs , but also in the hardware required for execution . Debugging refers to the activity of diagnosing and finding such errors, be it using a debugger or other methods.
Origin of name
The term "debugging" (to German debug ) is frequently Grace Hopper attributed to a legend that she liked to tell himself that is not quite correct. In 1947, while working on the Mark II, a moth caused a relay on this computer to fail. Grace Hopper's team found the moth and stuck it in the logbook along with the sentence “First actual case of bug being found.” (“The first time that a bug was actually found.”). As a result, the term “debugging” for “troubleshooting” is said to have become established in the team. The term “bug” (for insect, beetle, pest) had been used in English among engineers since the 19th century as a term for malfunctions and was mentioned as slang in Webster's New International Dictionary as early as 1937. With Fix (Engl. Fix for repair, repair) the elimination of a will bug called.
Functions of a debugger
- the control of the program flow , in particular through breakpoints and the single-step processing of commands
- the inspecting data, such. B. the registers, the current program code as assembler or high-level language source text, the general data in fixed and volatile memories, the generation of advanced data interpretations, for example through a call stack functionality or the display of input / output registers, tables and high-level languages Structures
- the modifying of memories such. B. the main memory, the external input / output states and the registers of the processor core
Depending on the debugger and the nature of the hardware, it is also possible to receive feedback and error states ( exceptions ) from the target system. Memory access errors, invalid opcodes and command sequences for which input or output variables are questionable, such as an attempted division by zero, are of particular interest here.
A fundamental distinction is made between remote debugging of remote systems and debugging, which is carried out within the processor system to be examined with on-board resources. A special version is remote debugging using a simulation of the target system using a processor simulation and other elements. Debugging a virtual machine represents an intermediate form between the two types, whereby the virtual machine basically has the character of a local application as well as an independent system. Overcoming the processor architecture is at least fundamentally a certain amount of effort. Depending on the design, even clock-accurate determinations of the runtime behavior are possible during debugging. B. a simulation does not necessarily have to run in real time. When simulating semiconductors in the ASIC , FPGA or PLC category , both hardware and software simulations are common tools that are accessible to the developer via a correspondingly special debugger.
Simple troubleshooting at assembler level is possible at any time with a system designed for this purpose. Some high-level languages, such as scripts or various BASIC variants, on the other hand, can often only be examined line-based on the source text level. Extended functionalities, e.g. For example, symbols, structures and function names can be resolved with the presence of symbol information in a special file or embedded in a binary program (e.g. DWARF debug information). Advanced debugger and development systems can still use e.g. B. record data during operation, prepare performance analyzes and visualize concurrent processes.
A debugger is systematically most comparable with what is done in electrical engineering and electronics by the typical measuring devices and aids, e.g. B. a logic tester, a multimeter, an oscilloscope or a signal generator, is available as an option for the commissioning and monitoring of corresponding systems.
Modern debuggers have the option of translating changes to the source text directly during program execution and then continuing the program. This technique is also known as just in time debugging . A debugger is often part of a program development environment .
In addition, a debugger can also be used in reverse engineering to better and more quickly understand external programs by tracing and examining variables.
In object-oriented runtime systems , in parallel programming or in distributed systems , it is very difficult or even impossible in practice to define an exact program sequence. Some development systems therefore forego the use of runtime debuggers, but usually allow the definition of breakpoints at which the status of all variables can be analyzed after the program stop. So -called post-mortem debuggers are also used in this context for exception handling , i.e. after program interruptions that are forced, for example, by an error .
Breakpoints
The most important ability of a debugger is to set breakpoints . These make it possible to interrupt its execution at any point in a program and thus enable the register and memory to be examined.
Software breakpoints are most often used, which temporarily change a byte in the program to be examined. This byte is the instruction to trigger a breakpoint interrupt , to stop the program execution when the byte is changed.
However, this option includes the restriction that the program to be examined may not check itself for integrity (for example by checking a checksum , see also cyclical redundancy check ). Malware programmers exploit this weakness of the soft breakpoints, for example, to make the analysis of a malicious program more difficult or even to prevent it.
The hardware breakpoints are not subject to this restriction because they do not change the program to be examined. Hardware breakpoints are implemented directly in the processor; however, it has only limited resources for this, so that only a limited number of these breakpoints are available.
Many debuggers allow the programmer to set conditional breakpoints. In addition to the instruction where the program execution is to be stopped, the programmer also specifies the instruction for a Boolean expression . The debugger only interrupts program execution when the specified line of code has been reached and the Boolean expression is true at the same time.
However, so that the debugger can test whether the Boolean expression is true, it must temporarily interrupt the program execution and check the Boolean expression, whereupon the debugger either continues the program execution or leaves the program in the interrupted state.
Tools used for troubleshooting
software
- Compuware Xpediter - z / OS Debugger
- DDT - DEC / CP / M debugger
- DEBUG.EXE - MS-DOS Debugger
- gdb - the GNU debugger, a Unix tool
- HiTOP - Debugger / IDE from Hitex Development Tools
- IBM Debug Tool - z / OS Debugger and IDE
- iSYSTEM BlueBox with winIDEA - In circuit debugger for embedded systems
- Lauterbach TRACE32 - In circuit debugger for embedded systems
- SEGGER Ozone - Debugger for Embedded Systems
- ltrace - shows dynamic library and system calls in Linux
- Microsoft Visual Studio IDE Integrated Debugger + Remote Debugger
- OllyDbg - Debugger with GUI for Windows operating systems
- SoftICE - Kernel mode debugger for DOS and Microsoft Windows up to Windows XP ( 1987-2000 (last published))
- strace ( Linux ), truss ( Solaris ) - displays system calls
- The Interactive Disassembler - Disassembler for many computer architectures; also includes a debugger for the x86 architecture
- TOD - a so called Omniscient Debugger for Java
- Turbo Debugger from Borland
- valgrind - for debugging and profiling x86 Linux programs
- Visual DuxDebugger - Debugger Disassembler for Windows 64-bit
- WinDbg , KD / CDB, NTSD - Windows debugger for x86, Itanium, and x64 systems, part of the Debugging Tools for Windows
- W32DASM - Debugger and Disassembler
hardware
See also
literature
- David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems , AMACOM, 2002. ISBN 0-8144-7168-4 .
- Ann R. Ford, Toby J. Teorey: Practical Debugging in C ++ , Prentice Hall, 2002. ISBN 0-13-065394-2 .
- Matthew A. Telles, Yuan Hsieh, Matt Telles: The Science of Debugging , The Coriolis Group, 2001. ISBN 1-57610-917-8 .
- Andreas Zeller : Why Programs Fail: A Guide to Systematic Debugging , Dpunkt Verlag, 2005. ISBN 3-89864-279-8 .
- Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka: The Developer's Guide to Debugging , 2nd edition, CreateSpace Independent Publ., 2012. ISBN 978-1-4701-8552-7 .
- John Robbis: Debugging Microsoft .NET 2.0 applications , practical (...) with Visual Studio 2005 , German, MicrosoftPress Germany, 2007, ISBN 978-3-86645-408-8
Web links
- Why Programs Fail - Website for the book Why Programs Fail by A. Zeller, with program examples and teaching material (600 slides!)