Misplaced Pages

#102897

27-439: 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 " trap " occurs when

54-415: A status register and a program counter , the latter of which signifies the next instruction to be executed. Therefore, it is specifically the program counter that is assigned to this location. A set of pseudo registers are set to what they would have contained if the program had been given control directly. It may be necessary to amend some of these to point to other pseudo "control blocks" depending on

81-416: A forward direction. Interactive debuggers include the ability to modify code and step forward based on updated information. Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the program, changing the history if desired, and watch how

108-485: A monitoring program can detect these even without a storage protect key . Illegal operations: some operating systems (or hardware) require the application program to be in the correct "mode" for certain calls to the Operating system. Instruction simulation can detect these conditions before execution. Hot spot analysis & instruction usage by counting the instructions executed during simulation (which will match

135-400: A program step by step ( single-stepping or program animation ), stopping ( breaking ) (pausing the program to examine the current state) at some event or specified instruction by means of a breakpoint , and tracking the values of variables. Some debuggers have the ability to modify the program state while it is running. It may also be possible to continue execution at a different location in

162-450: 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. Some debuggers include a feature called " reverse debugging ", also known as "historical debugging" or "backwards debugging". These debuggers make it possible to step

189-472: A program's execution backwards in time. Various debuggers include this feature. Microsoft Visual Studio (2010 Ultimate edition, 2012 Ultimate, 2013 Ultimate, and 2015 Enterprise edition) offers IntelliTrace reverse debugging for C#, Visual Basic .NET, and some other languages, but not C++. Reverse debuggers also exist for C, C++, Java, Python, Perl, and other languages. Some are open source; some are proprietary commercial software. Some reverse debuggers slow down

216-562: A single specific language while others can handle multiple languages transparently. For example, if the main target program is written in COBOL but calls assembly language subroutines and PL/1 subroutines, the debugger may have to dynamically switch modes to accommodate the changes in language as they occur. 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

243-450: Is a low-level debugger or a machine-language debugger it shows the line in the disassembly (unless it also has online access to the original source code and can display the appropriate section of code from the assembly or compilation). Typically, debuggers offer a query processor, a symbol resolver, an expression interpreter, and a debug support interface at its top level. Debuggers also offer more sophisticated functions such as running

270-423: Is a simulation model , usually coded in a high-level programming language , which mimics the behavior of a mainframe or microprocessor by "reading" instructions and maintaining internal variables which represent the processor's registers . Instruction simulation is a methodology employed for one of several possible reasons: Instruction-set simulators can be implemented using three main techniques: An ISS

297-464: Is dynamically allocated from memory 'pools' on a task by task basis. Most modern microprocessors have at least one of these features in their CPU design to make debugging easier: 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. This

SECTION 10

#1732790945103

324-420: Is especially true for high level language programs which effectively 'disguise' the extent of machine code instructions by their nature. Some of these software simulators remains to be used as tools for assembly language and Instruction Set Architecture teaching, with some specifically designed using multiple simulation layers and ISA to ISA simulation, with the ability to even design ISAs and simulate them. In

351-483: Is often provided with (or is itself) a debugger in order for a software engineer / programmer to debug the program prior to obtaining target hardware. GDB is one debugger which has a compiled-in ISS. It is sometimes integrated with simulated peripheral circuits such as timers , interrupts , serial ports , general I/O ports , etc. to mimic the behavior of a microcontroller . The basic instruction simulation technique

378-428: Is the process of stepping back in time through source code to understand what is happening during execution of a computer program . Typically, debugging and debuggers , tools that assist a user with the process of debugging, allow users to pause the execution of running software and inspect the current state of the program. Users can then step forward in time, stepping into or over statements and proceeding in

405-786: 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. Debugging is often used to illegally crack or pirate software, which is usually illegal even when done non-maliciously. Crackme's are programs specifically designed to be cracked or debugged. These programs allow those with debuggers to practice their debugging ability without getting into legal trouble. Some widely used debuggers are: Earlier minicomputer debuggers include: Mainframe debuggers include: Instruction set simulator An instruction set simulator ( ISS )

432-413: Is the same regardless of purpose: first execute the monitoring program passing the name of the target program as an additional input parameter. The target program is then loaded into memory, but control is never passed to the code. Instead, the entry point within the loaded program is calculated, and a pseudo program status word (PSW) is set to this location. The Program Status Word (PSW) is composed of

459-606: 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 gdb and dbx , provide console-based command line interfaces . Debugger front-ends are popular extensions to debugger engines that provide IDE integration, program animation , and visualization features. Record and replay debugging , also known as "software flight recording" or "program execution recording", captures application state changes and stores them to disk as each instruction in

486-507: The execution of a target program can help to highlight random errors that appear (or sometimes disappear) while monitoring but not in real execution. This can happen when the target program is loaded at a different location than normal because of the physical presence of the monitoring program in the same address space. If the target program picks up the value from a "random" location in memory (one it doesn't 'own' usually), it may for example be nulls (X"00") in almost every normal situation and

513-621: The first volume of The Art of Computer Programming , Donald Knuth wrote: "In the author's opinion, entirely too much programmers' time has been spent in writing such [machine language] simulators and entirely too much computer time has been wasted in using them." In the following section, however, the author gives examples of how such simulators are useful as trace or monitor routines for debugging purposes. Typical trace output from simulation by monitoring program used for test & debugging: Simulators Other Time travel debugging Time travel debugging or time traveling debugging

540-549: The hardware and operating system. It may also be necessary to reset the original parameter list to 'strip out' the previously added program name parameter. Thereafter, execution proceeds as follows: For test and debugging purposes, the monitoring program can provide facilities to view and alter registers, memory, and restart location or obtain a mini core dump or print symbolic program names with current data values. It could permit new conditional "pause" locations, remove unwanted pauses and suchlike. Instruction simulation provides

567-419: The number executed on the actual processor or unmonitored execution), the simulator can provide both a measure of relative performance between different versions of algorithm and also be used to detect "hot spots" where optimization can then be targeted by the programmer. In this role it can be considered a form of performance analysis as it is not easy to obtain these statistics under normal execution and this

SECTION 20

#1732790945103

594-712: The opportunity to detect errors BEFORE execution which means that the conditions are still exactly as they were and not destroyed by the error. A very good example from the IBM S/360 world is the following instruction sequence that can cause difficulties debugging without an instruction simulation monitor. The number of instructions to perform the above basic "loop" (Fetch/Execute/calculate new address) depends on hardware but it could be accomplished on IBM S/360 /370/390/ES9000 range of machines in around 12 or 13 instructions for many instruction types. Checking for valid memory locations or for conditional "pause"s add considerably to

621-403: The overhead but optimization techniques can reduce this to acceptable levels. For testing purposes this is normally quite acceptable as powerful debugging capabilities are provided including instruction step , trace and deliberate jump to test error routine (when no actual error). In addition, a full instruction trace can be used to test actual (executed) code coverage . Occasionally, monitoring

648-550: The program cannot normally continue because of a programming bug or invalid data. For example, the program might have tried to use an instruction not available on the current version of the CPU or attempted to access unavailable or protected memory . When the program "traps" or reaches a preset condition, the debugger typically shows the location in the original code if it is a source-level debugger or symbolic debugger , commonly now seen in integrated development environments . If it

675-497: The program to bypass a crash or logical error. 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. Early microcomputers with disk-based storage often benefitted from

702-462: The program works OK. If the monitoring program shifts the load point, it may pick up say X"FF" and the logic would cause different results during a comparison operation. Alternatively, if the monitoring program is now occupying the space where the value is being "picked up" from, similar results might occur. Re-entrancy bugs: accidental use of static variables instead of "dynamic" thread memory can cause re-entrancy problems in many situations. Use of

729-417: The target by orders of magnitude, but the best reverse debuggers cause a slowdown of 2× or less. Reverse debugging is very useful for certain types of problems, but is still not commonly used yet. 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. Some debuggers operate on

#102897