Debuggers are specific to the machines, operating systems, and languages that they support. Much of a debugger has to be re-implemented for each new machine, so debuggers that work with a variety of machines and operating systems can get unwieldy. Improvements to debuggers may be lost unless they are re-implemented as users move to new machines. If retargeting debuggers were easier, other improvements would be more valuable. This thesis describes the design and implementation of ldb, a prototype retargetable debugger. Dealing with symbol-table formats is one of the most machine-dependent aspects of debuggers. ldb eliminates this machine dependence by using one format on all machines. The format is a language---a dialect of PostScript, which is extensible and can represent procedures. ldb reduces retargeting effort associated with variations in run-time support by controlling its target process using a debug nub, which is a small piece of object code linked with the target program. Mu...

This paper describes a novel approach to event-based debugging. The approach is based on a (coarsegrained) dataflow view of events: a high-level event is recognized when an appropriate combination of lower-level events on which it depends has occurred. Event recognition is controlled using familiar programming language constructs. This approach is more flexible and powerful than current ones. It allows arbitrary debugger language commands to be executed when attempting to form higher-level events. It also allows users to specify event recognition in much the same way that they write programs. This paper also describes a prototype, Dalek, that employs the dataflow approach for debugging sequential programs. Dalek demonstrates the feasibility and attractiveness of the dataflow approach. One important motivation for this work is that current sequential debugging tools are inadequate. Dalek contributes toward remedying such inadequacies by providing events and a powerful debugging language

A data breakpoint associates debugging actions with programmer-specified conditions on the memory state of an executing program. Data breakpoints provide a means for discovering program bugs that are tedious or impossible to isolate using control breakpoints alone. In practice, programmers rarely use data breakpoints, because they are either unimplemented or prohibitively slow in available debugging software. In this paper, we present the design and implementation of a practical data breakpoint facility. A data breakpoint facility must monitor all memory updates performed by the program being debugged. We implemented and evaluated two complementary techniques for reducing the overhead of monitoring memory updates. First, we checked write instructions by inserting checking code directly into the program being debugged. The checks use a segmented bitmap data structure that minimizes address lookup complexity. Second, we developed data flow algorithms that eliminate checks on some classe...

Programmers spend considerable time debugging code. Symbolic debuggers provide some help but the task still remains complex and difficult. Other than breakpoints and tracing, these tools provide little high level help. Programmers must perform many tasks manually that the tools could perform automatically, such as finding which statements in the program affect the value of an output variable under a given testcase, what was the value of a given variable when the control last reached a given program location, and what does the program do differently under one testcase it does not do under another. If the debugging tools provided explicit support for such tasks, the whole debugging process would be automated to a large extent.

Programmers spend a significant part of their time debugging, yet most of them simply add print statements and avoid debugging tools. Although the user interface of debuggers has improved significantly in the past decade, their basic debugging methodologies have changed little. This thesis examines single-process sequential debuggers and attempts to elucidate their weaknesses. Target-state exploration and conditional program execution are essential idioms that cannot be practiced e#ectively with existing debuggers. State exploration seeks answers to queries such as detecting a linked list containing a negative element and finding where that element was added. Previous work has focussed on the use of source-language interpreters and graphical interactive exploration as solutions to the state-exploration problem, but these cannot e#ectively search for a negative element in a linked list, specify a search for it, etc. This thesis describes Duel, a very high-level language designed specifi...

Microscopic analysis of malicious code (malware) requires the aid of a variety of powerful tools. Chief among them is a debugger that enables runtime binary analysis at an instruction level. One of the important services provided by a debugger is the ability to stop execution of code at an arbitrary point during runtime, using breakpoints. Software breakpoints support an unlimited number of breakpoint locations by changing the code being debugged so that it can be interrupted during runtime. Most, if not all, malware are very sensitive to code modification with self-modifying and/or self-checking (SM-SC) capabilities, rendering the use of software breakpoints limited in their scope. Hardware breakpoints supported by the underlying processor, on the other hand, use a subset of the processor register set and exception mechanisms to provide breakpoints that do not entail

Abstract not found

Locating bugs is one of the most time-consuming tasks in debugging. Though external resources, such as explicit knowledge bases or formal specifications, can reduce the debugging time, this information either may not be readily available or may be too limited for real-world software. So in general, most debuggers try to reduce the time by providing analysis tools for the programmer to reduce the search space for bugs and to guess at the bug type, location, or both. We review the current state-of-the-art in debugging and point out three shortcomings that deserve more attention. First, the programmer has to perform the analysis and keep track of the results himself while he tries to locate faults. Second, the programmer needs (but lacks) automated decision support to help him evaluate program behavior as he tries to reduce the search space for bugs. Third, the debuggers that support fault location guessing do not point out the statements most likely to be faulty. Our objective is to redu...

The degree to which hardware and operating systems support debugging strongly influences the caliber of service that a debugger can provide. We survey the different forms in which such support is available. We limit our survey to lower-level debugger design issues such as accessing the debugged program's state and controlling its execution. The study concentrates on those types of support that make overall debugger performance efficient and that support debugger features for ferreting out hard-to-find bugs. We conclude with an overview of state-of-the-art debuggers and a proposal for a new debugger design.

Interactive debuggers allow users to specify conditions upon which the debugger stops the program being debugged so that the user can examine the state of the program. This stopping point is generally called a breakpoint. The most commonly used form of breakpoint, a control breakpoint, specifies the place in the program to stop. This type of breakpoint is well understood and implemented efficiently in most debuggers. W atchpoints are a special kind of breakpoint, a data breakpoint, that stop the program when the value of an expression changes. It has proven difficult to develop efficient watchpoint implementations and although a number of efficient mechanisms have been proposed, most debuggers still use the simplest and slowest. I have implemented variants of watchpoints in GDB, the GNU source-level debugger. This work shows that there are a number of practical implementations of watchpoints that perform much better than the common implementation. The watchpoint implementations that I ...