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...

As computer systems are becoming increasingly complex, directing tools are gaining in importance. Directing denotes two classes of activities, monitoring and controlling. Monitoring is used for collecting information about the program behavior. Controlling is used to modify the program state in order to change program's future behavior. Some characteristic directing tools are debuggers and performance monitors. Dynascope is a directing platform, which provides basic monitoring and controlling primitives. These primitives are used in building advanced directing applications for networked and heterogeneous environments. Dynascope is integrated with existing programming tools and uses only generic operating system and networking primitives. This paper describes the design and implementation of the directing server, the central component of Dynascope. Dynascope is being used in several applications, including relative debugging, steering agents, and simulator testing. 1 Introduction Incre...

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.

This paper reports the distributed embedded software development that we have built for HAGAR. Our environment is based on a processor-pool architecture. It supports many remote users while providing a single system image. The environment, as seen by programmers, is similar to the environment used by UNIX application developers. A user logs in to our system for an embedded software development session. The system hides the fact the target hardware is different from the host, allowing the user to use the standard UNIX paradigm to load and test embedded software. To avoid the delay problems with simulation, most of the embedded software in our environment is tested on real processors rather than on simulated processors. On the other hand, we closely integrate the software development platform with the hardware development platform for testing our software against non-existing hardware. This development environment was built in a short time. We saved time by exploiting vendor tools and by overlapping our developments with vendors'. Our environment started to work even before Intel shipped its final version of the 80960CA CPU