Study On Debugging Tools

A debugger or debugging tool is a computer program that is used to test and debug other programs (the "target" program). 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 operationfull or partial simulationto limit this impact. A "crash" happens when the program cannot normally continue because of a programming bug. 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 "crashes" 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 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).

CODE VIEW DEBUGGER

CodeView was a standalone debugger created by David Norris at Microsoft in 1985 as part of its development toolset. It originally shipped with Microsoft C 4.0 and later. It also shipped with Visual Basic for MS-DOS, Microsoft Basic PDS, and a number of other Microsoft language products. It was one of the first debuggers on the MS-DOS platform that was full-screen oriented, rather than line oriented. When running, CodeView would present the user with several windows that could be tiled, moved, sized and otherwise manipulated via the keyboard or mouse, with CodeView 4.x providing a richer interface. Some of the windows included: Code window - the code window showed the currently debugged code in its source code context. Data window - a hexadecimal dump of a user-specified memory area. Watch window - a contextual display of variables by name. Locals window - a contextual display of variables local to the current function. Command window - user commands (using the same or similar syntax as DEBUG.COM and symdeb) could be entered here. Assembly window - the assembly (machine code) was displayed, allowing for singlestepping through functions. Register window - to visualize the 80x86 register contents, including segments, flags and the FPU (CodeView existed before MMX and other SIMD extensions). Output window - a window showing startup operations and debugging information relating to breakpoints, hardware breaks (interrupt 0 and 3), etc. 386 mode - CodeView supported 8086, 80286 and 80386 and later processors. 386 enhanced mode was activated by a menu option, allowing for 32-bit registers and disassembly.

Monochrome monitor support - CodeView supported debugging on either a single color (CGA, EGA or VGA) monitor with page/memory swapping between the user application and the CodeView screen, or through a feature which utilized a separate monochrome

monitor. The monochrome monitor existed in memory address space 0xb0000, while the color monitor existed at 0xb8000 for text and 0xa0000 for graphics. Use of the monochrome monitor with its separate memory address space allowed debugging graphics applications without affecting the display, as well as all text modes. Monochrome monitor support was limited to 25 lines, whereas color monitors could utilize 25, 43 or 50 line mode, allowing for more information on the screen at the same time.

DATA DISPLAY DEBUGGER

Data Display Debugger, or DDD, is a popular free software (under the GNU GPL) graphical user interface (using the Motif toolkit) for command-line debuggers such as GDB, DBX, JDB, HP Wildebeest Debugger (WDB), XDB, the Perl debugger, the Bash debugger, the Python debugger, and the GNU Make debugger. DDD is an entry in the GNU Project. DDD has GUI front-end features such as viewing source texts and its interactive graphical data display, where data structures are displayed as graphs. A simple mouse click dereferences pointers or views structure contents, updated each time the program stops. Using DDD, you can reason about your application by watching its data, not just by viewing it execute lines of source code. DDD is used primarily on Unix systems, and its usefulness is complemented by many open source plug-ins available for it.

ECLIPSE DEBUGGER
Eclipse is an open-source community that develops open platforms and products. The community says its projects "are focused on building an open development platform consisting of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle". The Eclipse Foundation is a non-profit corporation which acts as the steward of the Eclipse community. However, as the Eclipse community states, "Eclipse means a lot of different things to different people. To some Eclipse is a [...] Java development environment. To others, Eclipse is a flexible environment to experiment with new computer languages or extensions to existing languages. [...]"In the software world, a simple mention of "Eclipse" usually refers to the Eclipse software development kit (SDK). The Eclipse SDK consists of the Eclipse Platform, Java developments tools and the Plug-in Development Environment. The Eclipse Platform is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java. By means of various plug-ins, it can be used to develop applications in various programming languages including Ada, C, C++, COBOL, Java, Perl, PHP, Python, R, Ruby (including Ruby on Rails framework), Scala, Clojure, Groovy and Scheme. It can also be used to develop packages for the software Mathematica. Development environments include the Eclipse Java development tools (JDT) for Java, Eclipse CDT for C/C++, and Eclipse PDT for PHP, among others. The initial codebase originated from

VisualAge. The Eclipse SDK (which includes the Java development tools) is meant for Java developers. Users can extend its abilities by installing plug-ins written for the Eclipse Platform, such as development toolkits for other programming languages, and can write and contribute their own plug-in modules. Released under the terms of the Eclipse Public License, Eclipse SDK is free and open source software. It was one of the first IDEs to run under GNU Classpath and it runs without issues under IcedTea.

FUSION DEBUGGER
FusionDebug an interactive step debugger for Adobe ColdFusion and Railo CFML Engine. Step through code line-by-line, step into, step over or out of code to better understand how CFML code is running. FusionDebug can be used as an alternative to using CFOUTPUT/CFDUMP statements. Benefits of using the debugger No code changes Goes beyond using CFOUTPUT/CFDUMP Can debug Flex, Ajax, Web Service and Flash Remoting Requests easily Change variables on the fly Debug requests from any user Understand the flow of requests Debug complex applications View stack traces Releases 2010 : FusionDebug version 3.5 2009 : FusionDebug version 3.0.1 2009 : FusionDebug version 3.0 2007 : FusionDebug version 2.0.1 2007 : FusionDebug version 2.0 2005 : FusionDebug version 1.0

JINX DEBUGGER
Jinx is a concurrency debugger that deterministically controls the interleaving of workloads across processor cores, focusing on shared memory interactions. Using this deterministic approach, Jinx is able to increase the frequency of occurrence of elusive shared memory bugs, sometimes called Heisenbugs. Jinx works by dynamically building a set of potential

interleavings (i.e. alternate eventualities, or execution scenarios, that will occur under some future condition) that are most likely to result in concurrency faults, and quickly tests those execution paths to surface concurrency problems such as deadlocks, race conditions and atomicity violations that are found in multiprocessing applications. Unlike model checkers, Jinx does not require the specification of a model. Unlike dynamic and static code analysis methods, Jinx is notable in that it produces no false positives (spurious bug reports). This is because Jinx actually tests the scenarios that are likely to be bugs, as opposed to just inferring those scenarios by analyzing source code or observing the execution of a program. Jinx is implemented as a hypervisor, giving it the ability to observe the effects of all elements of the software environment on thread interleaving. Jinx operates independently of any programming language or threading libraries or tools. Jinx has been developed by Corensic in Seattle, Washington based on research performed at the University of Washington and initially presented at the ASPLOS conference of 2009.

JAVA PLATFORM DEBUGGER

The Java Platform Debugger Architecture is a collection of APIs to debug Java code. Java Debugger Interface (JDI) - defines a high-level Java language interface which developers can easily use to write remote debugger application tools. Java Virtual Machine Tools Interface (JVMTI), a native interface which helps to inspect the state and to control the execution of applications running in the Java Virtual Machine (JVM). Java Virtual Machine Debug Interface (JVMDI)- JVMDI was deprecated in J2SE 5.0 in favor of JVM TI, and was removed in Java SE 6. Java Debug Wire Protocol (JDWP) - defines communication between debuggee (a Java application) and debugger processes.

TURBO Debugger
Turbo Debugger (TD) was a machine-level debugger for MS-DOS executables, intended mainly for debugging Borland Turbo Pascal (TP), and later Turbo C (TC) programs, sold by Borland. This tool was a full-screen debugger displaying both TP or TC source and corresponding assembly-language instructions, with powerful capabilities for setting breakpoints, watching the

execution of instructions, monitoring machine registers, etc. TD could be used for programs not generated by Borland compilers, but without showing source statements; it was by no means the only debugger available for non-Borland executables, and not a significant general-purpose debugger. Although Borland's Turbo Pascal (TP) had useful single-stepping and conditional breakpoint facilities, the need for a more powerful debugger became apparent when TP started to be used for serious development. Initially a separate company, Turbopower, produced a debugger, TDebug, and also their Turbo Analyst and Overlay Manager for Turbo Pascal for TP versions 1-3. Turbopower released T-Debug Plus 4.0 for TP 4.0 in 1988, but by then Borland's Turbo Debugger had been announced. The original Turbo Debugger was a stand-alone product introduced in 1989,along with Turbo Assembler and the second version of Turbo C. To use Turbo Debugger with source display, programs, or relevant parts of programs, had to be compiled with TP or TC with a conditional directive set which added debugging information to the compiled executable, which related source statements and corresponding machine code. The debugger would then be started (TD did not debug within the development IDE). After debugging the program would be recompiled without debugging information to reduce its size. Later Turbo Debugger, the stand-alone Turbo Assembler (TASM), and Turbo Profiler were included with the compilers in the professional Borland Pascal and Borland C++ versions of the more restricted Turbo Pascal and Turbo C++ suites for MS-DOS. After the popularity of Microsoft Windows ended the era of MS-DOS software development, Turbo Debugger was bundled with TASM for low-level software development. For many years after the end of the MS-DOS era, Borland supplied Turbo Debugger with the last console-mode Borland C++ application development environment, version 5, and with Turbo Assembler 5.0. For many years both of these products were sold even though active development stopped on them. With Borland's reorganization of their development tools as CodeGear, all references to Borland C++ and Turbo Assembler vanished from their web site. The debuggers in later products such as C++ Builder and Delphi are based on the the Windows debugger introduced with the first Borland C+ + and Pascal versions for Windows. The final version of Turbo Debugger came with several versions of the debugger program: TD.EXE was the basic debugger; TD286.EXE ran in protected mode, and TD386.EXE was a virtual debugger which used the TDH386.SYS device driver to communicate with TD.EXE. The TDH386.SYS driver also added breakpoints supported in hardware by the 386 and later processors to all three debugger programs. TD386 allowed some extra breakpoints that the other debuggers did not (I/O access breaks, ranges greater than 16 bytes, and so on). There was also a debugger for Windows 3 (TDW.EXE). Remote debugging was supported. Most of the information in the paragraph above, and much more, is to be found in documentation files supplied with Turbo Debugger, in particular "TURBO DEBUGGER TIPS AND HINTS", HELPME!.TD and "USING THE HARDWARE DEBUGGING FEATURES", HDWDEBUG.TD.

Turbo Debugger and emulation The original 1.0 release of Turbo Debugger for MS-DOS will run under simple MS-DOS emulators (DOSEMU, in an MS-DOS Window in Windows 95, 2000, etc.) The later versions attempt to control the underlying machine in a way not allowed by the host operating system (in which the emulator is running) and therefore do not work.[5] The last MS-DOS version of TD.EXE, 3.2, does run successfully in the 32-bit Windows XP NTVDM (i.e., in a DOS window, invoked with CMD.EXE), but TD286.EXE and TD386.EXE do not. Hardware breakpoints supported by the 386 and later processors are available if TDH386.SYS is loaded by including "DEVICE=<path>TDH386.SYS" in a CONFIG.NT file invoked when running TD.EXE.

JSWAT DEBUGGER
JSwat is a graphical Java debugger front-end, written to use the Java Platform Debugger Architecture. JSwat is licensed under the Common Development and Distribution License and is freely available in both binary and source code form. In addition to the graphical interface, there is a console based version which operates very much like jdb, the debugger included with the Java Development Kit. Features include breakpoints with conditionals and monitors; colorized source code display; graphical display panels showing threads, stack frames, visible variables, and loaded classes; command interface for more advanced features; Java-like expression evaluation, including method invocation.

WINDBG DEBUGGER
WinDbg is a multipurposed debugger for Microsoft Windows, distributed on the web by Microsoft. It can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger.

WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging. WinDbg also has the ability to automatically load debugging symbol files (e.g., PDB files) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version). This is a very helpful and time saving alternative to creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs). Recent versions of WinDbg have been distributed as part of the free Debugging Tools for Windows suite, which shares a common debugging engine between WinDbg and command line debuggers like KD, CDB, and NTSD. This means that most commands will work in all alternative versions without modification, allowing users to use the style of interface with which they are most comfortable.

MICROSOFT VISUAL STUDIO DEBUGGER

The Microsoft Visual Studio Debugger is a debugger that ships along with all versions of Microsoft Visual Studio. This debugger owes much of its feel and functionality to CodeView, a standalone, text-based debugger that shipped with Microsoft Visual C++ version 1.5 and earlier. More advanced features of the most recent versions of this debugger include: Full symbol and source integration. Edit and continue support, enabling source code to be modified and recompiled on-thefly without having to exit the current running program or restart the debugger (32 bit applications only). Remote machine debugging. Attaching and detaching to and from processes (both on the current machine and a remote machine). Integrated debugging across programs written in both .NET and native Windows languages (calls from C# to C++, for example). Full support for C++, including templates and the standard library Debugging ASP.NET Web Services. Tracing into DLL code when symbolic debugger information is present. Standard as well as more advanced breakpoint features, including conditional, address, data breakpoints. Many ways of viewing program state and data, including multiple watch windows, threads, call stack, and modules. The way library and user data types are displayed can be configured (e.g., to show contents of a container class, rather than its raw structure).

Scriptability or the ability to control via a macro or scripting language. Any language which can talk to COM can be used. Local and remote debugging of SQL stored procedures on supported versions of Microsoft SQL Server.

The main shortcoming of the Visual Studio Debugger is its inability to trace into kernel-mode code. However, this is possible using a free VisualDDK extension. Alternatively, kernel-mode debugging of Windows is generally performed by using WinDbg, KD, or SoftICE. The Visual Studio Debugger also has no ability to debug Lambda-Expressions or Linq. This is because of the high complexity the debugger would grow to. However, most developers working with Lambda expressions are able to visualize the data through the several memory windows. Edit-and-continue is held by many developers as Microsoft's greatest asset given to developers. A program that is running in memory, that encounters a simple mistake, can be corrected without having to stop the current program or exit the debugger. This feature allows very common mistakes to be corrected easily and with great time savings over other solutions which require exiting the program, making the change, recompiling, and then navigating back through the running program to the previous location, including those available by the GNU Compiler Collection chain and debuggers like GDB and DBX. Still other developers believe that such "sloppy programming techniques" represent a greater philosophical issue related to the mindset of the developer, and should be addressed in other ways such as "teaching them proper coding techniques." This division over belief systems and coding methodology philosophies often causes staunch debate and even moderate hostility between some of the more zealot in both camps. Debugger Canvas steps through code in the debugger in Visual Studio Ultimate 2010.

GNU DEBUGGER
The GNU Debugger, usually called just GDB and named gdb as an executable file, is the standard debugger for the GNU software system. It is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal, Fortran, Java and partially others.

Features: GDB offers extensive facilities for tracing and altering the execution of computer programs. The user can monitor and modify the values of programs' internal variables, and even call functions independently of the program's normal behavior. GDB target processors (as of 2003) include: Alpha, ARM, AVR, H8/300, System/370, System 390, X86 and its 64-bit extension X86-64, IA-64 "Itanium", Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, and VAX. Lesser-known target processors supported in the standard release have included A29K, ARC, ETRAX CRIS, D10V, D30V, FR-30, FR-V, Intel i960, 68HC11, Motorola 88000, MCORE, MN10200, MN10300, NS32K, Stormy16, and Z8000. (Newer releases will likely not support some of these.) GDB has compiled-in simulators for even lesser-known target processors such like M32R or V850.[6] GDB is still actively developed. As of version 7.0 new features include support for Python scripting. At least since version 7.3, "reversible debugging" allowing a debugging session to step backward, much like rewinding a crashed program to see what happened has been added.