TL;DR: In this article, a debug buffer is used as a video FIFO for buffering pixels for display on a monitor and a dedicated bus is connected to an external DAC rather than to the external ICE when debugging is not being performed.
Abstract: A microprocessor die contains several processor cores and a shared cache. Trigger conditions for one or more of the processor cores are programmed into debug registers. When a trigger is detected, a trace record is generated and loaded into a debug queue on the microprocessor die. Several trace records from different processor cores can be rapidly generated and loaded into the debug queue. The external interface cannot transfer these trace records to an external in-circuit emulator (ICE) at the rate generated. The debug queue transfers trace records to the external ICE using a dedicated bus to the ICE so that bandwidth is not taken from the memory bus. The memory bus is not slowed for debugging, providing a more realistic debugging session. The debug buffer is also used as a video FIFO for buffering pixels for display on a monitor. The dedicated bus is connected to an external DAC rather than to the external ICE when debugging is not being performed.
TL;DR: In this article, a small and efficient set of primitives for debugging a distributed application that runs on a plurality of processors connected by a common network is presented. But these primitives permit a user to debug a distributed program in a manner similar to debugging a non-distributed application.
Abstract: This invention provides a small and efficient set of primitives for debugging a distributed application that runs on a plurality of processors connected by a common network. These primitives permit a user to debug a distributed application in a manner similar to debugging a non-distributed application. The invention allows a user to step into and return from a remote procedure call in exactly the same manner as a local procedure call. The invention also allow a user to set breakpoints in a server for specific clients and to specify conditions under which a particular remote call from a client should trap in a server. These capabilities greatly simplify the process of debugging distributed applications such as client-server programs.
TL;DR: In this paper, the authors propose a circuit for diagnosing and debugging a processor for executing a stream of instructions that includes a set of debug registers for identifying an instruction or data address breakpoint.
Abstract: A circuit for diagnosing and debugging a processor for executing a stream of instructions that includes a set of debug registers for identifying an instruction or data address breakpoint; a processor for generating a debug exception in response to an instruction or data address in the stream of instructions matching the instruction or data breakpoint stored in the set of debug registers and a debug configuration register for enabling transfer of program control to one of a plurality of destinations in response to the debug exception. The debug configuration registers may designate system management mode, JTAG routine or a software debug interrupt handler as the destination.
TL;DR: In this article, a lookup table of debugging flags is used to map the debugging flags to memory locations containing the present state of the flags. And a debugging message handler decodes the debugging message using the table, and the module reports or alters the debugging flag accordingly.
Abstract: In a computing system, debug flags for software development, testing, and debugging of a module of the operating system are retrieved and set. The module under development is provided with a debugging message handler and a lookup table of debugging flags. The table maps the debugging flags to memory locations containing the present state of the flags. A debugging message is generated at the application-level by a user desiring to monitor or alter the state of the debugging flags. The debugging message handler decodes the debugging message using the table, and the module reports or alters the debugging flag accordingly. In this manner, real-time program evaluation and control can be achieved without the conventional debugging software packages.
TL;DR: In this paper, a system and method for extracting custom debug signals from an integrated circuit chip is presented, where the debug signals are normally extracted via bonded custom debug pads during the testing of the chip, and made available in production chips via the external I/O bus of the integrated circuit.
Abstract: A system and method for extracting custom debug signals from an integrated circuit chip. The custom debug signals, which are normally extracted via bonded custom debug pads during the testing of the chip, are made available in production chips, where the custom debug pads are not bonded and therefore unavailable, via the external I/O bus of the integrated circuit. In a preferred embodiment, the integrated circuit operates normally to drive standard debug data from internal nodes of the integrated circuit onto the I/O bus during idles cycles in the normal operation of the integrated circuit. Selection means may be set to drive the custom debug signals onto the I/O bus during idle cycles of normal integrated circuit operation rather than the standard debug data.
TL;DR: It is described how dataflow can be used to provide a very rich control mechanism that is well suited to the parallel environment and illustrated by a worked example.
Abstract: This paper discusses a new debugging strategy for parallel programs, called parallel relative debugging. Relative debugging allows a user to compare the execution of one program to another, and this can be used to trace errors. This technique has been found to significantly aid in problem determination. A prototype sequential relative debugger called Guard, has already been constructed and has been used in a number of real world situations. However the control logic it uses is not sufficiently powerful to support the debugging of parallel applications in this paper we describe how dataflow can be used to provide a very rich control mechanism that is well suited to the parallel environment. We illustrate the system by a worked example.
TL;DR: This paper describes a DSP application development platform, a Miaosofi Windows-based Digital Signal Processing (DSP) system designed primarily for professional audio applications, that can be used to debug DSP firmware when no host application software has been written.
Abstract: This paper describes a DSP application development platform. The Lake DSP “Huron” hardware platform is a Miaosofi Windows-based Digital Signal Processing (DSP) system designed primarily for professional audio applications. “Huron” contains a 256 channel digital audio bus running at audio sample rates (nominally 48kHz). External audio signals are interfaced to the system by input and output modules which plug into an I/O card. Multiple DSP cards can be added to the system, each with four processors, SUM, DRAM, and inter-processor communication facilities. A development and debugging system integrated with Lake application software has been developed for this platform. The development environment consists of an object oriented Host Interface Library, an object oriented Debug Library, and a debugger application (LakeMon). The same debug environment can be used to debug DSP firmware when no host application software has been written, right through to the observation and debugging of a complete GUl-driven application.
TL;DR: Analysts debug real-time distributed systems by viewing timing behavior in the context of four possible faults and applying a method to determine which fault caused the violation.
Abstract: Analysts debug real-time distributed systems by viewing timing behavior in the context of four possible faults. Animations and graphs of execution history make it easy to see process interactions. By applying a method to determine which fault caused the violation, analysts can go beyond timing analysis to efficiently correct the program.
TL;DR: This paper discusses issues in the design and implementation of a flexible debugging tool and its integration into a parallel software engineering environment.
Abstract: We discuss issues in the design and implementation of a flexible debugging tool and its integration into a parallel software engineering environment.
TL;DR: In this article, the authors present a debugging memory which is programmed with a debugging routine on the integrated circuit socket, connecting an external computer terminal to the input/output port, and activating the computer system such that the central processing unit executes the debugging routine.
Abstract: In a computer system which has a system memory, an integrated circuit socket that is normally used for mounting a BIOS memory thereon, an input/output port, and a central processing unit connected to the system memory, the integrated circuit socket and the input/output port, a method of debugging in the computer system includes mounting a debugging memory which is programmed with a debugging routine on the integrated circuit socket, connecting an external computer terminal to the input/output port, and activating the computer system such that the central processing unit executes the debugging routine and such that the central processing unit is capable of downloading and executing software instruction codes from the external computer terminal.
TL;DR: Testbed as discussed by the authors provides debugging and dynamic modification facilities for real-time distributed systems within the Testbed embedded systems environment, exploiting natural breakpoints present in a state machine programming model to perform monitoring and debugging actions.
Abstract: The paper describes the debugging and dynamic modification facilities provided for real time distributed systems within the Testbed embedded systems environment. We exploit natural break-points present in a state machine programming model to perform monitoring and debugging actions. This technique can avoid the probe effect which is a major problem in debugging concurrent and real-time systems. We describe the background debugging technique in which debugging is partially automated to further reduce interference. Testbed also supports a dynamic modification technique that avoids re-starting the application, which may be inappropriate for embedded systems that run continuously without a notion of stopping time. Background debugging and dynamic modification complement each other in Testbed to provide a powerful alternative to traditional debugging methods.
TL;DR: This paper proposes a new advanced cross debugging architecture based on a network transparent and connection independent client-server model that enables more flexible interactive debugging of a program, including the design and the implementation of such toots.
Abstract: Real-time software tools and effective operating system supports are essential to reduce the complexity of real-time software developments such as a switching system. In this paper, we propose a new advanced cross debugging architecture based on a network transparent and connection independent client-server model. It enables more flexible interactive debugging of a program, including the design and the implementation of such toots. It also enables easy and efficient monitoring of the behaviour of target system.
TL;DR: Debugging a C0"UnicatiOBQS Chip were not confident of the behavior of specially designed cache registers used in the FIFO to speed up the operation of the chip, so a concise model in the SMV language was built and it was determined that the error arose from a condition in which the same address appeared twice in theFIFO.
Abstract: Debugging a C0\"UnicatiOBQS Chip were not confident of the behavior of specially designed cache registers used in the FIFO to speed up the operation of the chip. After checking many properties with SMV, Chen was unable to find any errors in the FIFO. He concluded that the error must be in some other part of the circuit. Eventually, Chen determined that all the major components of the circuit were correct, meaning that the error must be caused by the way in which they were connected. He built a concise model for the chip in the SMV language. The model did not describe the hardware in the chip that was clearly unrelated to the cause of the error; and the width of the data path was reduced as much as possible to cut the number of states. Chen's specifications were written in temporal logic that described the abnormal behavior. Running on a workstation, the SMV model-checker took less than half an hour to determine that the error arose from a condition in which the same address appeared twice in the FIFO. This condition-the result of incorrect resetting of address recycling circuits-caused the data to be sent twice, the second time overwriting the first, leading to duplication or disappearance of the data, depending upon the instant that the data was read. The abnormal execution trace found by the model-checker was more than 50 clock cycles long. This meant that, starting in the initial state, it took at least 50 clock cycles for the error to occur. Since the width of the data path in the actual chip was larger and the input data tended to be more random, the error occurred only after a considerable period of time, which explained why it was so hard to find.
TL;DR: The Amulet toolkit contains a comprehensive collection of monitoring and debugging tools, including an interactive ‘‘Inspector’’, provided in a machine-independent way in C++ without using hooks into the compiler, symbol tables or the runtime stack.
Abstract: Although interactive, direct manipulation applications are known to be difficult to design and implement, the toolkits with which they are built generally do not contain any particular support for debugging. The Amulet toolkit contains a comprehensive collection of monitoring and debugging tools, including an interactive ‘‘Inspector.’’ These tools are provided in a machine-independent way in C++ without using hooks into the compiler, symbol tables or the runtime stack. Some of these capabilities are based on wellknown techniques, but others are innovations that have never been provided before. Based on our experience with writing and debugging interactive applications, we have provided tools to address the most common and difficult programming bugs. The capabilities include: viewing values of objects as they change; breaking into the debugger when values change; viewing the inheritance and grouping hierarchies of objects; feedback for why objects are not visible or not interactive; tracing of constraint dependencies; and various techniques to search for objects. In addition, programmers can edit the values displayed in the Inspector, supporting rapid prototyping without requiring a C++ interpreter. These features make debugging interactive applications written using Amulet is substantially easier than with other toolkits.
TL;DR: Integrating testing and debugging around a core technology has made it possible for test results to be early, precise and easy to relate to system internals, even if the test itself is a black-box test.
Abstract: Testing and debugging of large-scale, distributed, concurrent software systems, like telecommunications software, is costly and time consuming. Apart from the direct costs of developing and executing the tests, large costs are incurred if test results are late, imprecise or hard to relate to system internals. By integrating testing and debugging around a core technology, we have made it possible for test results to be early, precise and easy to relate to system internals, even if the test itself is a black-box test. The core technology is a program execution control facility for distributed concurrent programs, which started as a programmable thread debugger but turned out to have a wider scope. We have tried out the combination of debugging and regression testing, with very encouraging results. We are interfacing to existing tools to obtain TTCN, Message Sequence Charts and SDL capability. Some important side effects of integrated testing and debugging are also mentioned, notably the ability to debug effectively the test suites for a telecommunications software system. On-line extension is also enabled by our core technology, its role with respect to testing and debugging is briefly discussed.
TL;DR: This paper provides initial study results of a method for the debug of embedded computer systems differing from the typical intrusive and non-intrusive methods, which employs a 'priori knowledge of both the software text segment and the processor architecture to supplant intrusive acquisition of measurement information.
Abstract: In many of the popular, high performance processors, the ability to debug embedded software is complicated by the advanced architecture of the processors. When attempting to debug the embedded software, the most difficult debug problems leave few clues with which to identify offending actions. Modern software debugging systems often require software and/or hardware intrusion into the process under test. This "intrusion" often modifies the behavior of the system under test and therefore hampers the correction of errors. Methods which employ only minimum intrusion often require extensive measurements, which are rapidly becoming either very difficult or impossible to achieve. This paper provides initial study results of a method for the debug of embedded computer systems differing from the typical intrusive and non-intrusive methods. The primary difference is that the current initial study employs a 'priori knowledge of both the software text segment and the processor architecture to supplant intrusive acquisition of measurement information. The method further combines the a 'priori information with exclusively non-intrusive measurements to assist in the isolation of system errors. The current paper supplies case studies based upon the Motorola's 68020 processor. The 68020 was selected since it contains many of the advanced architecture features which tend to create the complications. Therefore the 68020 serves as a representative model and also provides concrete illustrations. The current method provides for no special measurement ports requiring non-standard configurations. Measurements include only readily available information provided by implemented configurations (e.g., ports, busses).
TL;DR: Based on the strategy, one-phase one-line debugging of parallel programs is available and basic algorithms and an example are given in the paper.
Abstract: Nondeterminacy is a main obstacle of parallel debugging. Current debugging strategies either detect non-dcterminacy separately, or control the execution in a two-phase manner. Here we present a strategy called “state freezing”. Based on the strategy, one-phase (we call one-line) debugging of parallel programs is available. Basic algorithms and an example are given in the paper.