The Heinsenburg Debugging Technology

by James Blandy and Michael Snyder

In January 2000, Cygnus was bought by Red Hat.

Content
  1. The Problem
  2. The Cygnus Solution: Introspect
  3. The Implementation of Introspect
  4. Future Directions

Abstract

Probably the most widely familiar method of debugging programs is breakpoint debugging. In this method, you are allowed to specify locations in your program (breakpoints) where the program execution will suddenly stop, giving you the opportunity to examine the program's state. You can then either let the program execute one or more instructions at a time, or allow it to continue until another breakpoint, and examine the state again.

Breakpoint debugging works very well for serial programs that do not interact with any other dynamic entities (other programs or real-world devices). However, programs in the parallel and real-time domains may have their behavior and results altered if interrupted by a debugger. Events may go undetected, message queues may overflow, and moving parts may fail to stop in time, causing real-world damage to machines or people.

One solution is to instrument the code, but the most frequently used way to do this is to insert print statements by hand, which has numerous disadvantages and limited power. A tool to instrument a program at runtime would need many of the capabilities of a debugger; and indeed, a typical debugger has most of the capabilities both to perform the instrumenting, and to help analyze the resulting trace data. A debugger could easily plant tracing instrumentation in the executing program, and just as easily could display the values of program data and arbitrary expressions collected, together with the associated source code; and it could do it all interactively.

The Cygnus approach uses the popular GNU debugger, GDB, both to set up and to analyze trace experiments. In a trace experiment, the user specifies program locations to trace and what data to collect at each one (using the full power of the source language's symbolic expressions). A simplified, non-symbolic description of the trace experiment is downloaded to a separate trace collection program. Then the program is run while the specially written trace collection program collects the data. Finally, GDB is used again to review the traced events, stepping from one tracepoint execution to the next and displaying the recorded data values just as if debugging the program in real time; or GDB's scripting language is used to produce a report of the collected data, formatted to the user's specification.

Next >