TIDE: A Generic Debugging Framework — Tool Demonstration —

A language specific interactive debugger is one of the tools that we expect in any mature programming environment. We present applications of TIDE: a generic debugging framework that is related to the ASF+SDF Meta-Environment. TIDE can be applied to different levels of debugging that occur in language design.Firstly, TIDE was used to obtain a full-fledged debugger for language specifications based on term rewriting. Secondly, TIDE can be instantiated for any other programming language, including but not limited to domain specific languages that are defined and implemented using ASF+SDF.We demonstrate the common debugging interface, and indicate the amount of effort needed to instantiate new debuggers based on TIDE.     

Grammar‐driven generation of domain‐specific language debuggers

Domain‐specific languages (DSLs) assist a software developer (or end‐user) in writing a program using idioms that are similar to the abstractions found in a specific problem domain. Tool support for DSLs is lacking when compared with the capabilities provided for standard general‐purpose languages (GPLs), such as Java and C++. For example, support for debugging a program written in a DSL is often non‐existent. The lack of a debugger at the proper abstraction level limits an end‐user's ability to discover and locate faults in a DSL program. This paper describes a grammar‐driven technique to build a debugging tool generation framework from existing DSL grammars. The DSL grammars are used to generate the hooks needed to interface with a supporting infrastructure constructed for an integrated development environment that assists in debugging a program written in a DSL. The contribution represents a coordinated approach to bring essential software tools (e.g. debuggers) to different types of DSLs (e.g. imperative, declarative, and hybrid). This approach hides from the end‐users the accidental complexities associated with expanding the focus of a language environment to include debuggers. The research described in this paper addresses a long‐term goal of empowering end‐users with development tools for particular DSL problem domains at the proper level of abstraction without depending on a specific GPL. Copyright © 2007 John Wiley & Sons, Ltd.     

Dynamic Query-Based Debugging of Object-Oriented Programs

Program errors are hard to find because of the cause-effect gap between the instant when an error occurs and when the error becomes apparent to the programmer. Although debugging techniques such as conditional and data breakpoints help in finding errors in simple cases, they fail to effectively bridge the cause-effect gap in many situations. This paper proposes two debuggers that provide programmers with an instant error alert by continuously checking inter-object relationships while the debugged program is running. We call such tool a dynamic query-based debugger. To speed up dynamic query evaluation, our debugger implemented in portable Java uses a combination of program instrumentation, load-time code generation, query optimization, and incremental reevaluation. Experiments and a query cost model show that selection queries are efficient in most cases, while more costly join queries are practical when query evaluations are infrequent or query domains are small. To enable query-based debugging in the middle of program execution in a portable way, our debugger performs efficient Java class file instrumentation. We call such debugger an on-the-fly debugger. Though the on-the-fly debugger has a higher overhead than a dynamic query-based debugger, it offers additional interactive power and flexibility while maintaining complete portability.     

Empirical studies on programming language stimuli

Comprehending and debugging computer programs are inherently difficult tasks. The current approach to building program execution and debugging environments is to use exclusively visual stimuli on programming languages whose syntax and semantics has often been designed without empirical guidance. We present an alternative: Sodbeans, an open-source integrated development environment designed to output carefully chosen spoken auditory cues to supplement empirically evaluated visual stimuli. Originally designed for the blind, earlier work suggested that Sodbeans may benefit sighted programmers as well. We evaluate Sodbeans in two experiments. First, we report on a formal debugging experiment comparing (1) a visual debugger, (2) an auditory debugger, and (3) a multimedia debugger, which includes both visual and auditory stimuli. The results from this study indicate that while auditory debuggers on their own are significantly less effective for sighted users when compared with visual and multimedia debuggers, multimedia debuggers might benefit sighted programmers under certain circumstances. Specifically, we found that while multimedia debuggers do not provide instant usability, once programmers have some practice, their performance in answering comprehension questions improves. Second, we created and evaluated a pilot survey analyzing individual elements in a custom programming language (called HOP) to garner empirical metrics on their comprehensibility. Results showed that some of the most widely used syntax and semantics choices in commercial programming languages are extraordinarily unintuitive for novices. For example, at an aggregate level, the word for , as in a for loop, was rated reliably worse than repeat by more than 673% by novices. After completing our studies, we implemented the HOP programming language and integrated it into Sodbeans.     

Designing a source-level debugger for cognitive agent programs

When an agent program exhibits unexpected behaviour, a developer needs to locate the fault by debugging the agent’s source code. The process of fault localisation requires an understanding of how code relates to the observed agent behaviour. The main aim of this paper is to design a source-level debugger that supports single-step execution of a cognitive agent program. Cognitive agents execute a decision cycle in which they process events and derive a choice of action from their beliefs and goals. Current state-of-the-art debuggers for agent programs provide insight in how agent behaviour originates from this cycle but less so in how it relates to the program code. As relating source code to generated behaviour is an important part of the debugging task, arguably, a developer also needs to be able to suspend an agent program on code locations. We propose a design approach for single-step execution of agent programs that supports both code-based as well as cycle-based suspension of an agent program. This approach results in a concrete stepping diagram ready for implementation and is illustrated by a diagram for both the Goal and Jason agent programming languages, and a corresponding full implementation of a source-level debugger for Goal in the Eclipse development environment. The evaluation that was performed based on this implementation shows that agent programmers prefer a source-level debugger over a purely cycle-based debugger.     

Back to the Future: Omniscient Debugging

This article presents TOD (trace oriented debugger), a prototype scalable omniscient debugger for Java, which aims at making omniscient debugging practical, at last. Omniscient debuggers, also known as back-in-time or reversible debuggers, record the whole history, or execution trace, of a debugged program and let the user freely explore it. This approach combines the advantages of both log-based (past activity is never lost) and breakpoint based debugging (interactive navigation, step-by-step execution, and complete stack inspection). Omniscient debuggers simulate step-by-step execution both forward and backward, avoiding having to rerun the whole program many times to pinpoint the bug's root cause. More importantly, they make it possible to navigate through the history of a program by following causal links, so questions that would otherwise require a significant effort can be answered instantly for instance, "When was variable x assigned a null value?" or "What was the state of object o when it was passed as an argument to method foo?".     

Extension Language Automation of Embedded System Debugging

Embedded systems contain several layers of target processing abstraction. These layers include electronic circuit, binary machine code, mnemonic assembly code, and high-level procedural and object-oriented abstractions. Physical and temporal constraints and artifacts within physically embedded systems make it impossible for software engineers to operate at a single layer of processor abstraction. The Luxdbg embedded system debugger exposes these layers to debugger users, and it adds an additional layer, the extension language layer, that allows users to extend both the debugger and its target processor capabilities. Tcl is Luxdbg's extension language. Luxdbg users can apply Tcl to automate interactive debugging steps, to redirect and to interconnect target processor input-output facilities, to schedule multiple processor execution, to log and to react to target processing exceptions, to automate target system testing, and to prototype new debugging features. Inclusion of an extension language like Tcl in a debugger promises additional advantages for distributed debugging, where debuggers can pass extension language expressions across computer networks.     

Experience with a portable debugging tool

Debugging tools are usually highly machine and compiler dependent programs that are either impossible to move or require a tremendous effort to move to another machine. This paper describes Ctrace, a portable debugging tool for the C language that provides the same, easy-to-use debugging environment on all machines. A similar debugger can be written for any language. Ctrace is a preprocessor that inserts source language debugging code into the program before compilation that, at execution time, prints the text of each source language statement along with the values of variables it uses and modifies. Redundant trace output from program loops is detected and eliminated. Tracing can be limited to selected statements or functions. Ctrace has shown its usefulness and popularity by its installation on over 200, computers at Bell Laboratories. It has proven its portability by being used to test software on four different operating systems and nine different processors.     

Stack virtualization for source level debugging

The compilation of high‐level languages to general‐purpose execution platforms poses some challenges when it comes to debugging. Typically, abstractions that are not natively supported by the execution platform must be emulated with intermediate data structures and function calls. Unfortunately, the details of the emulation are visible in the execution stack, and this unwanted information greatly reduces the effectiveness of debuggers. This paper presents a general method for constructing a virtual view of the stack, in order to mask intermediate function calls that were generated to emulate high‐level abstractions, or even to recover logical frame information that was lost during the compilation process. In particular, virtual views enable the visualization of two disjoint code representations (e.g. native code and interpreted code) as a single unified stack. We illustrate this method by showing how to handle the compilation of Bigloo, a dialect of the Scheme programming language. Copyright © 2006 John Wiley & Sons, Ltd.     

The Implementation Technology of the Mercury Debugger

Every programming language needs a debugger. Mercury now has three debuggers: a simple procedural debugger similar to the tracing systems of Prolog implementations, a prototype declarative debugger, and a debugger based on the idea of automatic trace analysis. In this paper, we present the shared infrastructure that underlies the three debuggers, and describe the implementation of the procedural debugger. We give our reasons for each of our main design decisions, and show how several of these decisions are rooted in our experience with the debugging of large programs working with large data structures.     

An Eclipse-based Integrated Environment for Developing Executable Structural Operational Semantics Specifications

The Structural Operational Semantics Development Tooling (SOSDT) Eclipse Plugin integrates the Relational Meta-Language (RML) compiler and debugger with the Eclipse Integrated Development Environment Framework. SOSDT, together with the RML compiler and debugger, provides an environment for developing and maintaining executable Structural Operational Semantics specifications, including the Natural Semantics big step variant of SOS specifications. The RML language is successfully used at our department for writing large specifications for a range of languages like Java, Modelica, Pascal, MiniML etc. The SOSDT environment includes support for browsing, code completion through menus or popups, code checking, automatic indentation, and debugging of specifications.     

An integrated performance analysis tool for SPMD data-parallel programs

A new generation of data parallel languages have been proposed whereby a user specifies how data structures are to be distributed amongst the processor nodes of a distributed-memory machine. Based on this information, the compiler then generates code for the parallel application. Although this approach significantly simplifies the development of the initial version of a parallel application, selection of good data distributions leading to efficient computations is often quite difficult. Therefore, performance debuggers are needed to yield insights into the data distribution effects. On the other hand, most of the existing approaches to performance debugging are very general and thus do not provide the user feedback in terms of the high level programming model or the source code of the parallel application. In this paper, we describe a novel approach to performance debugging of data parallel programs. The design and implementation of a visual performance debugger is described that is specifically targeted to meet the performance debugging requirements of a data-parallel programming model based on user-specified data distributions. The performance debugger is part of an integrated programming environment, called EPPP, which also supports a data parallel compiler and a parallel architecture simulator. Thus development and performance debugging of an application may be done either on the real hardware or by using the simulator. The code for EPPP can be obtained free of cost (contact web address, http://www.crim.ca/apar).     

Object‐oriented design patterns for debugging heterogeneous languages and virtual machines

Debugging multi‐language software systems requires examining and executing these systems at multiple levels of abstraction. Embedded systems, for example, often comprise a mix of assembly language device drivers and C language control code. Embedded systems increasingly utilize Java to support dynamic loading and run‐time reconfiguration. The RTEEM (Research version of the Tcl Environment for Extensible Modeling) debugger employs three design patterns in solving the problems of multi‐language embedded system debugging. The Reflective virtual machine (VM) pattern models a language‐neutral virtual machine abstraction, with language‐specific interfaces extending this abstraction. Reflection allows a debugger to inspect and control a target VM. The Chain of Responsibility is a classic pattern used to arrange language‐specific debugger command interpreters in a delegation chain. All interpreters share a single command syntax, but each interpreter adapts commands to its language abstraction by interacting with its language‐specific VM view. Composite is another classic pattern, used to combine objects into tree structures. RTEEM employs it to aggregate VM debugger chains into a hierarchy that supports uniform command syntax for debugging threads, processes, multiprocessor systems, and compositions of these entities. This paper illustrates how combining two classic design patterns with the VM abstraction as a pattern results in an architecture that is powerful and flexible in adapting to the debugging needs of heterogeneous, distributed embedded systems. Copyright © 2004 John Wiley & Sons, Ltd.     

An approach to the development of debuggers that use semantics of constructs of parallel programs

In the paper, a new approach to the development of interactive debuggers for parallel programs that use message-passing model is suggested. The basic idea of the approach is to design a debugger specific to a particular language or a parallel programming library and to use information about the semantics of constructs used in the parallel program for processing commands of the step-by-step execution and data representation. The development of the user interface and internal debugger structure, as well as their implementations in the debuggers for mpC programs and programs using the MPI library, are considered.Translated from Programmirovanie, Vol. 31, No. 1, 2005. Original Russian Text Copyright © 2005 by Kalinov, Karganov, Khorenko.     

A Machine-Independent Debugger

cdb is a simpe, source-level debugger for ANSI/ISO C programs compiled by lcc, a retargetable C compiler. cdb is completely independent of its target architecture. This independence is achieved by embedding a small amount of itself — a nub — in the program to be debugged and by having the compiler emit machine-independent symbol-table data and related code. This paper describes the design of a nub interface for debugging, a target-independent implementation of this interface for cdb, and the implementation of cdb itself. When compared to platform-specific debuggers, cdb's implementation is minuscule: the nub, debugger, and associated communications routines take about 1500 lines of C, and fewer than 600 lines were added to lcc's front end to emit symbol tables and breakpoint hooks. All this code is machine independent.     

Sequential debugging at a high level of abstraction

Efforts to build a better mousetrap for bugs in sequential programs are described. The resulting debugger, called Dalek, is intended to remedy limitations in conventional execution harnesses. Beyond the simple `stop and look' features offered by typical breakpoint debuggers, Dalek offers a rich control and query language. Dalek's linguistic capabilities for treating sequences of program events offer an improvement over scratch paper as a compensatory technology for human memory limitations. Example applications are given. The very interactive, dynamic style of debugging encouraged by Dalek is discussed     

Dynamic Reverse Code Generation for Backward Execution

The need for backward execution in debuggers has been raised a number of times. Backward execution helps a user naturally think backwards and, in turn, easily locate the cause of a bug. Backward execution has been implemented mostly by state-saving or checkpointing, which are inherently not scalable. In this paper, we present a method to generate reverse code, so that backtracking can be performed by executing reverse code. The novelty of our work is that we generate reverse code on-the-fly, while running a debugger, which makes it possible to apply the method even to debugging multi-threaded programs.