Abstract: A method of remote debugging comprises a first computer system that communicates with a second computer using a network connection. The first computer system controls the remote debugging and comprises a first operating system. The second computer system comprises a second operating system and software being tested. User input, in the form of debug commands, is received using a remote debugger in the first computer system to control the remote debugging session. The remote debugger translates a debug command into messages that are sent from the first computer system to the second computer system. The messages correspond to tasks that the target computer system performs to complete the debug command. During debugging, the target computer system transitions between polling or stopped mode and interrupt-driven mode by transitioning both the target operating system and network hardware in the target computer system that interfaces with the network.

Abstract: A dedicated debugging facility for tracing hardware and software faults in a distributed digital system. An event data capture circuit is integrated into each processing node in a distributed multinode system for capturing event data within each node under software control. The captured event data is stored in one of a plurality of variable-length trace data buffers in the node processor memory space for analysis or transfer. These dedicated trace data acquisition circuits provide continuously available trace data for the hardware and software functions within each node. Each variable-length trace data entry is stored in the trace data buffers according to a format of this invention that permits collection and assembly of trace data entries from throughout the distributed multinode system to debug local hardware or software and to debug internodal interconnection hardware and software.

Abstract: A method of controlling the execution of the threads of a first application such as a user application from a second application such as a debugger application running in a different address space. After initializing trace mode for the user application, the debugger waits for an event to occur on one of the threads of the user application. Upon the occurrence of an event on one of the user application threads, an event handler obtains control of the thread execution. The event handler suspends execution of the remaining threads in the application, posts the debugger and then suspends its own execution. When the debugger application has completed its debugging operations, it posts the event handler, which resumes execution of the suspended threads and returns control to the thread on which the event occurred. If a subsequent event occurs on one thread while a previous event on another thread is being processed, the event handler for the subsequent event places it in a deferred event queue for deferred processing. Events consisting of breakpoints are redriven rather than being placed on the deferred queue. The debugger application may hold selected threads in a suspended state following resumption of the remaining threads by setting hold flags associated with those threads.

Abstract: A program debugging system has a core unit that includes a plurality of debugger memory areas, each uniquely associated with a corresponding one of a plurality of debuggers. The core unit responds to an exception condition by selecting one debugger from the plurality of debuggers, selection being made by determining which one of the debuggers is associated with the program exception. Then, computer state information and debugger state information are stored into a selected one of the debugger memory areas that is exclusively associated with the selected debugger, and the selected debugger is activated. A new debugger may register with the core unit, so that the new debugger is added to the plurality of debuggers. The activated debugger may send a debugging command to the core unit, which responds by updating debugger state information based on the received debugging command, and storing the updated debugger state information into the selected debugger memory area. When a debugger relinquishes control of the computer, the core unit retrieves the updated debugger state information from the selected debugger memory area, and controls the hardware resources in accordance therewith. If the updated debugger state information includes an indication that a breakpoint is set, the core unit sets a breakpoint that includes information associating the set breakpoint with the selected debugger. When the breakpoint is triggered, the core unit identifies from the breakpoint information which of the debuggers the breakpoint is associated with, and activates the identified debugger.

Abstract: A monitor and debugger routine operable on a personal computer for facilitating the design of power-on self-test (POST) and basic input and output system (BIOS) code. The monitor and debugger routine is invoked by POST code early in the system initialization process, before most of the system hardware devices have been initialized and before the operating system has been invoked. The monitor and debugger routine uses minimal system resources--lower memory and a serial communications controller--and is accessed via an external communications and display device connected via a serial communications link generated by the serial communications controller. As so invoked, the monitor and debugger routine can be used to facilitate the design and debugging of the remaining portions of the system initialization code, hardware interface code, suspend and resume code, video code, and other code that cannot be debugged using standard debuggers that require a functioning BIOS and an operating system to operate.

Abstract: A common debugging strategy involves reexecuting a program (on a given input) over and over, each time gaining more information about bugs. Such techniques can fail on message-passing parallel programs. Because of nondeterminacy, different runs on the given input may produce different results. This nonrepeatability is a serious debugging problem, since an execution cannot always be reproduced to track down bugs. This paper presents a technique for tracing and replaying message-passing programs. By tracing the order in which messages are delivered, a reexecution can be forced to deliver messages in their original order, reproducing the original execution. To reduce the overhead of such a scheme, we show that the delivery'order of only messages involved inraces need be traced (and not every message). Our technique makes run-time decisions to detect and trace racing messages and is usuallyoptimal in the sense that the minimal number of racing messages is traced. Experiments indicate that only 1% of the messages are often traced, gaining a reduction of two orders of magnitude over traditional techniques that trace every message. These traces allow an execution to be reproduced any number of times for debugging. Our work is novel in that we adaptively decide what to trace, and trace only those messages that introduce nondeterminacy. With our strategy, large reductions in trace size allow long-running programs to be replayed that were previously unmanageable. In addition, the reduced tracing requirements alleviate tracing bottle-necks, allowing executions to be debugged with substantially lower execution time overhead.

Abstract: Most performance debugging and tuning of parallel programs is based on the "measure-modify" approach, which is heavily dependent on detailed measurements of programs during execution. This approach is extremely time-consuming and does not lend itself to predicting performance under varying conditions. Analytic modeling and scalability analysis provide predictive power, but are not widely used in practice, due primarily to their emphasis on asymptotic behavior and the difficulty of developing accurate models that work for real-world programs. In this paper we describe a set of tools for performance tuning of parallel programs that bridges this gap between measurement and modeling.Our approach is based on lost cycles analysis, which involves measurement and modeling of all sources of overhead in a parallel program. We first describe a tool for measuring overheads in parallel programs that we have incorporated into the runtime environment for Fortran programs on the Kendall Square KSR1. We then describe a tool that fits these overhead measurements to analytic forms. We illustrate the use of these tools by analyzing the performance tradeoffs among parallel implementations of 2D FFT. These examples show how our tools enable programmers to develop accurate performance models of parallel applications without requiring extensive performance modeling expertise.

Abstract: Lazy functional languages have non-strict semantics and are purely declarative, i.e. they support the notion of referential transparency and are devoid of side-effects. Traditional debugging techniques are, however, not suited for lazy functional languages, since computations generally do not take place in the order one might expect. Since algorithmic debugging allows the user to concentrate on the declarative aspects of program semantics, and will semi-automatically find functions containing bugs, we propose to use this technique for debugging lazy functional programs. Because of the non-strict semantics of lazy functional languages, arguments to functions are in general partially evaluated expressions. The user is, however, usually more concerned with the values that these expressions represent. We address this problem by providing the user with a strictified view of the execution trace whenever possible. In this paper, we present an algorithmic debugger for a lazy functional language based on strictification and some experience in using it. A number of problems with the current implementation of the debugger (e.g. too large trace size and too many questions asked) are also discussed and some techniques for overcoming these problems, at least partially, are suggested. The key techniques are immediate strictification and piecemeal tracing.

Abstract: Concurrent logic languages specify reactive systems which consist of collections of communicating processes. The presence of unintended suspended computations is a common programming error which is difficult to detect using standard debugging and testing techniques. We develop a number of analyses, based on abstract interpretation, which succeed if a program is definitely suspension free. If an analysis fails, the program may, or may not, be suspension free. Examples demonstrate that the analyses are practically useful. They are conceptually simple and easy to justify because they are based directly on the transition system semantics of concurrent logic programs. A naive analysis must consider all scheduling policies. However, it is proven that for our analyses it suffices to consider only one scheduling policy, allowing for efficient implementation.

Abstract: The invention includes systems and methods for debugging an application program running under an operating system such as Windows® 3.0 or 3.1. Such an operating system allows registration of callback functions with an operating system exception handler. The operating system exception handler calls the registered callback functions in response to an exception generated by the application program until one of the callback functions indicates that the exception has been resolved. The invention includes a monitor program which is installed in program memory concurrently with the application program. The monitor program registers itself with the operating system exception handler to be called in response to an exception generated by the application program. When called, the monitor callback function finds the startup parameters of the application program which generated the exception and starts a debugging program, using the startup parameters. The debugging program, in accordance with normal characteristics of debugging programs, registers itself with the operating system exception handler and then yields to the operating system. The monitor program returns control to the operating system without indicating that the exception has been resolved. Thereafter, the exception handler calls the registered debugging program to initiate debugging of the application program which generated the exception.

Abstract: Much of the recent research in software visualization has been polarized toward two opposite domains. In one domain that we call data structure and program visualization, low-level canonical views of program structures are generated automatically. These types of views, which do not require programmer input or intervention, can be useful for testing and debugging software. Often, however, their generic, low-level views are not expressive enough to convey adequately how a program functions. In the second domain called algorithm animation, designers handcraft abstract, application-specific views that are useful for program understanding and teaching. Unfortunately, since algorithm animation development typically requires time-consuming design with a graphics package, it will not be used for debugging, where timeliness is a necessity. However, we speculate that the application-specific nature of algorithm animation views could be a valuable debugging aid for software developers as well, if only the views could be easy and rapid to create. We have developed a system called Lens that occupies a unique niche between the two domains discussed above and explores the capabilities that such a system may offer. Lens allows programmers to build rapidly (in minutes) algorithm animation-style program views without requiring any sophisticated graphics knowledge and without using textual coding. Lens also is integrated with a system debugger to promote iterative design and exploration.

Abstract: A system and method for debugging a development computing system is disclosed. The BIOS in the development system includes a debug engine. Interrupt-handling macros in BIOS include an entry macro to direct debug output codes (e.g., port 80 and beep codes) to the debug engine. A near entry macro is added to BIOS-segment macros (e.g., F000 segment) which provides the offset of the debug engine. A far entry macro is added to non-BIOS-segment macros which provides the segment and offset of the debug engine. The debug engine sends the output codes to a remote host computer via a communication channel (e.g., a bi-directional parallel port) on the development system. The debug engine also saves the contents of various registers on the development system to the host computer. Thus, the invention can be used in a stackelss environment. Debug commands (e.g., memory dump, set break address) can be issued from the host computer to the development system via the communications channel. Such commands are executed on the development system in accordance with program instructions in the debug engine. Debug data associated with the development system may be sent to the host computer via the communications channel in response to a debug command (e.g., memory dump data). Thus, a user can interactively and remotely debug the development system.

Abstract: Correct optimization can change the behavior of an incorrect program; therefore at times it is necessary to debug optimized code. However, optimizing compilers produce code that impedes source-level debugging.Optimization can cause an inconsistency between where the user expects a breakpoint to be located and the breakpoint's actual location. This article describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code sufficiently closely for the user to use traditional debugging strategies.Optimization can also cause the value of a variable to be noncurrent—to differ from the value that would be predicted by a close reading of the source code. This article presents a method of determining when this has occurred, and shows how a debugger can describe the relevant effects of optimization. The determination method is more general than previously published methods; it handles global optimization and many flow graph transformations, and it is not tightly coupled to optimizations performed by a particular compiler. Necessary compiler support is also described.

Abstract: From the Publisher: WEB is a software system that facilitates the creation of readable programs. It was originally developed by Donald E. Knuth as he programmed the TEX typesetting system. Users of WEB are able to write programs of superior quality; produce state-of-the-art documentation; greatly reduce debugging time and maintain programs easily as conditions change. CWEB is a version of WEB for documenting C and C++ programs. WEB was adapted to C by Silvio Levy in 1987, and since then both Knuth and Levy have revised and enhanced the system in many ways, notably to support C++ and ANSI C. Thus CWEB combines TEX with two of today's most widely used professional programming languages. This book is the definitive user's guide and reference manual for the CWEB system. The CWEB software itself is freely available via anonymous ftp from labrea.stanford.edu on the Internet.

Abstract: Advanced processor and machine architectures need optimizing compilers to be efficiently programmed in high level languages. Therefore the need for source level debuggers that can handle optimized programs is rising. One difficulty in debugging optimized code arises from the problem to determine the values of source code variables. To ensure correct debugger behaviour with optimized programs, the debugger not only has to determine the variable's storage location or associated register. It must also verify that the variable is current, i.e. the value determined from that location is really the value that the variable would have in unoptimized code. We will deduce requirements on algorithms for currentness determination and present an algorithm meeting this requirements that is more general than previous work. We will also give first experiences with an implementation. To our knowledge this is the first implementation of a currentness determination algorithm for globally optimized code.

Abstract: Current software visualization tools are inadequate for understanding, debugging, and tuning realistically complex applications. These tools often present only static structure, or they present dynamics from only a few of the many layers of a program and its underlying system. This paper introduces "PV", a prototype program visualization system which provides concurrent visual presentation of behavior from all layers, including: the program itself, user-level libraries, the operating system, and the hardware, as this behavior unfolds over time. PV juxtaposes views from different layers in order to facilitate visual correlation, and allows these views to be navigated in a coordinated fashion. This results in an extremely powerful mechanism for exploring application behavior. Experience is presented from actual use of PV in production settings with programmers facing real deadlines and serious performance problems. >

Abstract: This invention provides a method for displaying circuit analysis results corresponding to parts of the circuit near the portion of the hardware description language (HDL) specification that generated that part of the circuit. The invention also includes a method for using probe statements in the HDL specification to mark additional points in the initial circuit that should not be eliminated during optimization. This improves the ability to display circuit analysis results near the appropriate part of the HDL specification.

Abstract: A source-level run-time software code debugging instrument (10) includes target access probe ("TAP") (12) and communications adapter ("COMDAP") (14) that process emulation commands provided by source-level debugging software operating on a host computer. The TAP includes a TAP CPU (28) that receives target CPU input signals and delivers target CPU output signals for controlling the execution of software code by the target circuit in accordance with command signals provided by the host computer. The TAP also includes programmable logic cell array (24) and RAM (34). The TAP logic cell array routes command and data signals to and from the TAP CPU, and the RAM stores an in-circuit emulation ("ICE") program used by the TAP to operate the target circuit. The COMDAP is physically separate from the TAP and provides an interface between the host computer and the TAP. The COMDAP includes a programmable logic cell array (44) and an EPROM (46). The COMDAP logic cell array routes command and data signals to and from the COMDAP, and the EPROM stores the commands for configuring the signal paths within the TAP and COMDAP logic cell arrays and stores the TAP ICE program. A flat cable assembly (16) provides a high-speed signal communications link between the TAP and the COMDAP. The TAP uses certain microprocessor signal features and source-level debugging software that runs on the host computer to provide a software engineer with a fully transparent window into the internal functioning of the TAP CPU while executing code in the target circuit environment.

Abstract: Debugging programs written in lazy functional languages is difficult, and there are currently no realistic, general purpose debugging tools available. The basic problem is that computations in gene ...

Abstract: We review the field of result-checking, discussing simple checkers and self-correctors. We argue that such checkers could profitably be incorporated in software as an aid to efficient debugging and reliable functionality. We consider how to modify traditional checking methodologies to make them more appropriate for use in real-time, real-number computer systems. In particular, we suggest that checkers should be allowed to use stored randomness: i.e., that they should be allowed to generate, pre-process, and store random bits prior to run-time, and then to use this information repeatedly in a series of run-time checks. In a case study of checking a general real-number linear transformation (for example, a Fourier Transform), we present a simple checker which uses stored randomness, and a self-corrector which is particularly efficient if stored randomness is allowed. >

Abstract: The problem of checking the correctness of distributed computations arises when debugging distributed algorithms, and more generally when testing protocols or distributed applications. For that purpose, one describes the expected behavior (or suspected errors) by a global property: for example, a predicate on process variables, or the set of admissible orderings on observable events. The problem is to check whether this property is satisfied or not during the execution. A relevant model for this study is the partial order of message causality and the associated state graph, called "lattice of consistent cuts". In this paper, we propose a general approach to trace checking, based on partial order theory. >

Abstract: A system is provided for executing and debugging multiple codes in a multi-architecture environment that includes a real X architecture (domain) and a simulated (Y) architecture (domain). The multiple code executing and debugging system comprises an X computer system having a memory with stored X and Y code and having the X architecture embodied therein. A detector is provided to detect calls from executing code in either domain for cross-domain services including execution of cross-domain routines. A jacketing system jackets cross-domain routine calls to interface the calling conventions of the calling and the called routines.

Abstract: A debugging system that allows programmers and software developers to more efficiently find and correct for errors in software applications. Preferred methods of the present invention includes the steps of setting and clearing watchpoints, statement stepping a program, and stopping a program from a debugger. One method provides for a table of watchpoints in the debugger. The debuggee is executed and, when an exception is generated, an address location of the exception is evaluated against the table of watchpoints to determine if a watchpoint has been encountered.

Abstract: One of the key pwblema iin debugging parallel pwgrama is that the behavior of a parallel program in response to a jbed input may be indeterminate. As a consequence of this non-repeatability, cyclic monitoring techniques for error isollation are not guaranteed to work. To tackle this problem, diferent trace and replay mechanwma have been proposed to support the debugging taak. In this paper we introduce a novel trace and replag mechanism for shared-memoty programa, baaed on Lamport cdocka. We compare the new scheme with Leblanc’s ‘Instant Replay’ and Netzer ’s ‘optimal tracing’. Our approach produces (much) smaller traces than both ezirting approaches. Moreover, in comparison with Ntstzer’s approach, our approach induces much less ovlerhead during the recording phase.

Abstract: In spite of growing needs in many areas, there is a lack of powerful graphical interfaces for interacting with large and complex sets of objects. Debugging, management and monitoring tools for object-oriented distributed systems or databases, for instance, need new interfaces that allow high quality visualization and interaction.We propose to use 3D interactive animations for representing large numbers of objects, complex relationships, and dynamic execution of concurrent activities. These innovative graphical representations, that we call virtual images, provide a consistent and intuitive solution for integrating various functionalities, considerably increasing the amount of information processed by the user. This technique has been successfully applied without specific hardware, demonstrating the feasibility of such interfaces on non specialized workstations.

Abstract: It is suggested that a functional model of monitoring in terms of the generation, processing, dissemination, and presentation of information can help determine the facilities needed to design and construct distributed systems. Implementation issues are also discussed, with attention given to the intrusiveness of monitoring systems and object-based implementation. It is concluded that generic monitoring services are important tools for managing distributed systems and for debugging during system development. Monitoring services may also be needed as part of the application itself, such as in process control and factory automation. >

Abstract: Acid is an unusual source-level symbolic debugger for Plan 9. It is implemented as a language interpreter with specialized primitives that provide debugger support. Programs written in the language manipulate one or more target processes; variables in the language represent the symbols, state, and resources of those processes. This structure allows complex interaction between the debugger and the target program and provides a convenient method of parameterizing differences between machine architectures. Although some effort is required to learn the debugging language, the richness and flexibility of the debugging envi­ ronment encourages new ways of reasoning about the way programs run and the conditions under which they fail.