Abstract: Many modern computer languages allow the programmer to define and use a variety of data types. Few programming systems, however, allow the programmer similar flexibility when displaying the data structures for debugging, monitoring and documenting programs. Incense is a working prototype system that allows the programmer to interactively investigate data structures in actual programs. The desired displays can be specified by the programmer or a default can be used. The default displays provided by Incense present the standard form for literals of the basic types, the actual names for scalar types, stacked boxes for records and arrays, and curved lines with arrowheads for pointers. In addition to displaying data structures, Incense also allows the user to select, move, erase and redimension the resulting displays. These interactions are provided in a uniform, natural manner using a pointing device (mouse) and keyboard.

Abstract: A programming system has been implemented in which annotated Petri nets are used as machine-processable high-evel design representations. The nets can be used to express the parallelism and the dynamic sequential dependencies found in complex software. They can then be interactively fired to facilitate debugging of the design. The nets are processed into a procedure language, called XL/1, to which a variety of transformations are applied in order to produce more efficient programs. These programs are generated for either a serial or a parallel processing environment. Finally, the XL/1 programs may be translated into PL/I or PL/S. The serial processing versions have been compiled and run successfully, but the parallel processing versions have not yet been run in a parallel processing environment.

Abstract: The transformations performed by an optimizing compiler have traditionally impeded interactive debugging in source language terms. A prototype system called Navigator has been developed for debugging optimized programs written in Cedar, an Algol-like language. Navigator can be used to monitor program execution flow in the presence of two optimizations: inline procedure expansion and cross-jumping (merging identical tails of code paths that join). This paper describes the problems that these two optimizations create for debugging and Navigator's solutions to these problems. The selected approach collects extra information during the optimization phases of compilation. At runtime, Navigator uses the additional information to hide the effects of the optimizations from the programmer.

Abstract: This work discusses some issues in the debugging of concurrent programs. A set of desirable characteristics of a debugger for concurrent languages is deduced from an examination of the differences between the debugging of concurrent programs and that of sequential ones. A debugger for a concurrent language, derived from CSP, is then presented. It is based upon a semantic model of the supported language. The debugger enables to compare a description of the program behaviour to the actual behaviour as well as to valuate assertions on the process state. The description of the behaviuor is given by a formalism whose semantics is also specified. The formalism can specify program behaviuors at various abstraction levels. Lastly some guidelines for the implementation of the debugger are shown and a detailed example of program description is analyzed.

Abstract: This paper describes an implementation of a system for programming using structured charts with interactive graphical support. It provides a graphical editor for the user to interactively build and edit programs using Nassi-Shneiderman diagrams (NSD)1 as the structured control constructs of logic flow. It can interpret a program in NSD chart form, and the execution sequence of the NSD is displayed at a graphical terminal. On-line debugging and testing facilities are available which allow the user to examine and modify the program under execution. The system has been designed with the aim of supporting the development, debugging, testing, documentation and maintenance of programs in the same environment.

Abstract: As part of a study of methods and strategies for problem solving in a distributed environment [Less80], we have been investigating techniques suitable for use in debugging programs written for implementation on distributed processing networks.Traditional debugging methods emphasize techniques that apply at the level of computation units and generally allow users to examine, and possibly alter, the state of a computation. Interactive debugging monitors are probably the most powerful implementations of the traditional method and usually permit a user to examine an entire snspshot of system state at any step of the computation. It is the job of the debugger (usually a person directing the error search) to determine what units are relevant to some problem, examine the units in whatever fashion is available, and then fit the results of these examinations into a model of how the computation works. Two elements essential to the successful completion of the debugging task are evident here: the ability to monitor, in some meaningful way, the relevant system activity so as to understand how system behavior differs from the debugger's model, and the ability to perform experiments based (implicitly or explicitly) on the information gathered. Through the interaction of these two elements a debugger attempts to gain an understanding of the causes of an error or at least to note where the implementation and the expected behavior differ.

Abstract: Digital Equipment Corporation's VAX-11 Debugger, usually called VAX DEBUG or simply DEBUG, is an interactive, symbolic, and multilingual debugger which runs on the VAX-11 series of computers under the VMS operating system. The following gives an overview of VAX DEBUG and examines how it solves some of the problems inherent in the design of any such debugger. Particular attention is paid to how its command language is designed, how it distinguishes between addresses and values in command input, how it solves the problem of accessing and organizing symbol table information, and how it exercises control over the user program.

Abstract: Using the Structured FORTRAN 77 software, this text provides an up-to-date treatment of numerical analysis for engineering and science problems. It presents the reader with problems, applications and an updated veiw of FORTRAN 77 by including a chapter on the extensions to the standard software. Each chapter contains practical programming information, a style/technique guide, debugging aids, summaries of FORTRAN statements, and key word glossaries. Over 600 examples and problems are used to illustrate the wide range of engineering and science applications for the software. This edition of the text includes nine new engineering application sections, featuring new topics like ozone measurements in the atmosphere, analysis of speech signals, and the use of GPS satellites to measure distances between locations on the Earth.

Abstract: The present study was designed to investigate the effect of delays in the response of the computer on the performance of the user and his satisfaction with the system. While it is generally assumed that computer responses should be no longer than several seconds, the present study showed no effect of 5- or 10-sec fixed or variable delays on subjects debugging a simple BASIC program. These results have important implications for the design of large, multiuser timesharing systems.

Abstract: As part of a study of methods and strategies for problem solving in a distributed environment [Less80], we have been investigating techniques suitable for use in debugging programs written for impl

Abstract: Chapter 12 is a most informative chapter. It describes soft­ ware costs and engineering. Many neophyte programmers fail to realize that programming is a high-level intellectual activity. Depending upon the motif, reason, and extent of the program, many unwanted pitfalls occur. The principal stages of a large software project are (a) specification, (£>) design, (c) coding, (d) testing, (e) integration, (/) documentation, and (g) maintenance. Each plays an important role that one should not neglect. Programming should follow tools which are useful in developing debugging other programs. The author details cost per line of program based on 1980 costs. These

Abstract: This paper introduces a modified version of path expressions called Path Rules which can be used as a debugging mechanism to monitor the dynamic behavior of a computation. Path rules have been implemented in a remote symbolic debugger running on the Three Rivers Computer Corporation PERQ computer under the Accent operating system.

Abstract: This is a market requirements statement for Interactive Debugging It is the result of a collaboration between the GUIDE/SHARE Language Futures Task Force (LFTF) and IBMThe LFTF was formed at meetings of SHARE and GUIDE in 1979 The objective of the task force was to provide IBM with the views of the user community on the future of the application development environment The Task force chose to limit its discussions primarily to "enhancements to the procedural languages and the environments in which they operate"

Abstract: This paper describes how MAP, a tool for understanding software, combines static analysis, some dynamic features, and an interactive presentation to aid programmers in debugging. Static analysis of the sort produced in optimizing compilers could provide programmers with useful information that they cannot get from dynamic debuggers. The challenge for designers of static analysis tools is to present the information in a useful form.

Abstract: The transformations performed by an optimizing compiler have traditionally impeded interactive debugging in source language terms. A prototype system called Navigator has been developed for debugging optimized programs written in Cedar, an Algol-like language. Navigator can be used to monitor program execution flow in the presence of two optimizations: inline procedure expansion and cross-jumping (merging identical tails of code paths that join). This paper describes the problems that these two optimizations create for debugging and Navigator's solutions to these problems. The selected approach collects extra information during the optimization phases of compilation. At runtime, Navigator uses the additional information to hide the effects of the optimizations from the programmer.

Abstract: This paper presents two topics: Implementation of a debugger through use of an incremental compiler, and techniques for fine-grained incremental compilation. Both the debugger and the compiler are ...

Abstract: This note describes RED, a remotely executed debugger capable of generating a real-time source level trace history of a high level language program executing on a microprocessor. The trace history consists of a display of the source statements of each basic block executed, annotated by the time at which execution of that block began. Basic blocks are traced rather than statements to reduce sampling bandwidth requirements while still retaining the ability to record the essential logical flow of programs. RED is intended to assist in debugging stand-alone high level language process control programs with real-time constraints.We outline two possible implementation schemes for generating the real-time trace history. In both, a "debugging co-processor" collects in a history buffer the values of the program counter (PC) and the corresponding value of a clock as each basic block begins execution. The debugger, which runs on the processor hosting the compiler and has access to the co-processor over a fast link, reconstructs a source level trace from the PC-time pairs in the history buffer. In one scheme, the language compiler emits an extra instruction at the beginning of each basic block in the program to output the value of the program counter to a parallel port connected to the debug processor. The second method makes use of an extended target memory space to provide tag bits denoting basic blocks. When an instruction is fetched, the debug processor detects the presence of the tag bits and buffers up the value of the corresponding program counter and time. The first method is simpler to implement, requiring only conventional, usually straightforward hardware additions to the target, but requires the execution overhead of the extra instructions. In both cases the debugger itself runs on the host processor and has access to tables generated during compile time of the source program.

Abstract: This paper presents two topics: implementation of a debugger through use of an incremental compiler, and techniques for fine-grained incremental compilation. Both the debugger and the compiler are components of the highly integrated programming environment DICE (Distributed Incremental Compiling Environment) which aims at providing programmer support in the case where the programming environment resides in a host computer and the program is running on a target computer that is connected to the host.Commands to the debugger command level includes all legitimate PASCAL statements. The debugger is machine-independent - it calls the incremental compiler which generates code for evaluation of commands, or modifies the machine code of the target program for insertion of breakpoints etc. Essentially all machine-dependences are isolated inside the code generator of the incremental compiler.

Abstract: Debugging techniques originated with low-level programming languages, where the memory dump and interactive word-by-word examination of memory were the primary tools. "High-level" debugging is often no more than low-level techniques adapted to high-level languages. For example, to examine the execution of an operational specification one state at a time by setting breakpoints, is superior to doing the same thing to a machine-language program, but only because the language level has improved; the debugging remains primitive. This paper attempts a radical definition of debugging level, and illustrates it with a technique for ordering the execution of concurrent processes in a way that follows their design structure.Division of a program into a collection of cooperating processes is a means of controlling the complexity of each process. However, in execution the program--development structure is ignored, with the result that the advantages of decomposition are lost. What the designer has divided and conquered, the debugger sees as an overwhelming monolith. The technique proposed here causes the focus of execution to follow the design structure, in a way that does not require detailed user direction.

Abstract: The research described here concerns the design and construction of an empirically-based debugging aid for first-time computer users, integrated into the Open University's SOLO programming environment. Its basis is an account of the processes involved as human experts debug faulty code, which account was later found to be supported by empirical tests on human experts. The account implies that an understanding of the intentions of the programmer is not essential to successful debugging of a certain class of programs. That class comprises programs written in a database-dependent language by users who are initially completely computer-naive and who during their course become competent to write simple programs which embody one or more basic AI techniques such as recursive inference. The debugging system, called AURAC, incorporates an explicit model of the debugging strategies used by human experts. Its understanding, therefore, is of programming in general and of the SOLO environment in particular. We present in the process a broad taxonomy of naive users' errors, showing that they can be divided into types, each type requiring a different debugging approach and indicating a different degree of expertise on the part of the perpetrator. SOLO is a conveniently delimited though nonetheless rich problem domain. Also described is a new version of SOLO itself (MacSOLO) which incorporates a large number of traps for the simple errors which plague novices, thus enabling AURAC to concentrate on the more interesting programming mistakes. AURAC is intended to operate after the event rather than whilst a program is actually being written, and is able via analysis of programming cliches and of data flows to isolate errors in the user's code. Where AURAC cannot analyse, or where its analysis yields nothing useful, it describes the corresponding section of code instead, so that the user receives a coherent output. MacSOLO and AURAC together form a unified system, based upon the principles of Simplicity, Consistency and Transparency. We show how these principles were applied during the design and construction phases.

Abstract: The SWAT (TM) debugger, Data General Corporation's Source Language Debugger, is an interactive, high-level, symbolic debugging tool. It offers its users a full complement of standard high-level debugging features with a simple command format modeled after that of Data General's AOS and AOS/VS operating system Command Line Interpreter. Multilingual capability was a primary design goal and this has resulted in the benefits of both wide user acceptance and product extensibility.This paper presents a summary of SWAT functionality and relates some of the experience of adding support for Data General Information Systems Division's recently announced AOS/VS Pascal and AOS/VS C languages.

Abstract: Real-time computer systems can be difficult to test when their timing characteristics influence the occurrence of problems. Because of this, tools for debugging real-time systems must account for the interference that they produce in the system they are monitoring. The debugging monitor for the Bell System 1A processor is an example of just such a tool. This paper examines the 1A processor debugging monitor, focusing on the division of the monitor into three separate devices: a hardware monitor that allows autonomous debugging; a resident monitoring program that allows debugging with a minimal interference to normal timing; and a separate mini-computer monitor that offers extended capability at the expense of unrestricted interference.

Abstract: This paper deals with issues that have emerged as a result of a successful implementation of a source level symbolic debugger for HP-1000 computer systems. By analyzing a user's thought processes during a debugging session we created a powerful and easy to use tool for program analysis.