When C++ first appeared outside AT&T Bell Laboratories in 1985, early adopters of the language enjoyed its power and expressiveness, but suffered from a dearth of specialized tools. The lack of a C++-specific debugger in particular hampered these pioneering programmers.

Happily, those days are mostly past. In addition to other tools, most C++ compiler vendors now also provide quite serviceable debuggers. Nevertheless, there remain some platforms for which only a C or assembly-oriented debugger (or even no debugger at all, in some embedded development environments) is available.

With a little foresight, however, C++ source-level debugging is possible even in these tool-poor environments. That's where MOOD -- the Minimal Object-Oriented Debugger -- comes in. MOOD, in keeping with its name, makes no pretense of providing every imaginable debugging service. It does, however, offer the ability to trace through program execution, set breakpoints, and interactively display the values of objects, as well as provide a framework on which more elaborate debugging facilities can be built, as required.

In essence, MOOD transfers control to a central routine each time an "interesting event" occurs. Such interesting events include program start and termination, function entry and exit, construction and destruction of objects, and user breakpoints. Whenever the central routine is invoked, it examines its internal state and the nature of the event to determine whether to initiate an interactive dialogue with the user, or simply to return and allow the program to continue its normal execution.

C++ makes it easy to gain control during these "interesting events" through the semantics of constructor and destructor operation. Whenever an object is created, its constructor is invoked. This guarantee by the language holds whether the object is global static (and hence initialized at the very beginning of the program execution), local static or automatic (and therefore initialized when control flows through its declaration), or on the heap (and thus initialized when it is explicitly allocated). The same is true of destructors whenever an object goes out of existence. Furthermore, not only are the constructor and destructor of the object itself invoked, but those of all of its base classes as well.

Normally, the purpose of running an object's constructor is to ensure that the object is internally consistent and to acquire any resources -- memory, files, devices, and so on -- it needs; the destructor is responsible for releasing those resources. However, it is perfectly reasonable for MOOD to piggyback on top of these normal constructor and destructor operations and then transfer control to the MOOD kernel at that time.

The application of constructor and destructor semantics to tracing object creation and destruction is obvious. If the object being created or destroyed is derived from a class whose constructor and destructor contain calls to the MOOD kernel, MOOD will have the opportunity to display a message or converse with the user at those times.

Using constructors and destructors to transfer control to MOOD at function entry and exit is equally straightforward, but perhaps a bit less obvious. In this case, a class must be defined whose constructor and destructor call the MOOD kernel indicating function entry and exit, and an auto object of that class must be declared as the first statement in each function whose execution is to be traced. When that object is created, at the beginning of the function's execution, MOOD will be informed of the function's invocation; when it is destroyed, that is, when the function returns, the destructor will notify MOOD that the function has terminated.

Extending these concepts to the start and finish of the entire program is simply a matter of defining a global static object whose constructor and destructor perform the necessary MOOD calls.

As can be inferred from the preceding section, MOOD is an intrusive debugger; that is, it is necessary to make certain changes to the source code of the program in order to debug it (the "foresight" mentioned at the start of this article). However, these changes are quite minor in nature and extent, as the following paragraphs demonstrate.

  class some_class: public virtual monitored {
  public:
     some_class(const char* obj_name):
     monitored(obj_name) { }
     void display() {
        fprintf(stderr, "i=%d\nj=%d\n", i, j);
        }
  private:
     int i;
     int j;
  };

  some_class an_object("an_object");

There are two important reasons that derivation from class monitored should be virtual instead of ordinary. First, in an elaborate inheritance hierarchy, the most-derived class (that is, the class used in the declaration of the object) may have several base classes, each of which is derived from class monitored. If ordinary inheritance were used, a verbose mode trace would include construction and destruction records for each of those classes when the object was created and destroyed. Making monitored a virtual base class causes the message to occur only once, because there is only a single instance of monitored in the object.

Second, deriving virtually from class monitored means that the most-derived class's constructor is both permitted and required to supply the argument to the class monitored constructor. This is important because only the object declaration itself "knows" the name of the object being declared, and virtual inheritance makes it both easy to pass that information along and impossible to forget to do so.

The final feature of MOOD.hxx that can be used by a program is insertion of conditional or unconditional breakpoints. Normally, MOOD allows user interaction (a "breakpoint") at any time a message would be printed in verbose tracing mode -- that is, at function entry and exit and object construction and destruction. If additional breakpoints are required, for instance, at some interesting point in an algorithm that does not correspond to one of the traced events, the programmer can insert explicit calls to the cond_break( ) function.

A call to cond_break( ) with no arguments is an unconditional break; MOOD will notify the user and enter an interactive dialogue, regardless of any other conditions. To make a breakpoint conditional, use a call that specifies a name (for example, cond_break(USER_BP, "my breakpoint")). Then, when the user tells MOOD that execution should proceed to a particular named event, MOOD will ignore conditional breakpoints whose names do not match the specified name.

  In its current form, MOOD recognizes the following commands:

  s           Step to the next "interesting event" and return to
              interactive mode

  g [<name>]  Go until the next event that has the
              specified name (which can be a function, object,
              or user breakpoint).  If no name is specified, go
              until the next user breakpoint or until the end of
              the program.

  d <addr>    Display an object, selected by the address
              printed out at the time the object was
              constructed.  This command calls the display()
              member function for the object whose
              "monitored" subobject is at the referenced
              address, which is displayed at construction time
              if in verbose mode.

  v           Turn on verbose mode.  This sends messages
              to stderr upon function entry and exit, and upon
              object construction and destruction.

  q           Turn off verbose mode.

The debugging facilities of MOOD are useful but quite rudimentary. They can be improved in various ways. For example, you could, without much effort, allow symbolic lookup of object names by maintaining a dynamic symbol table of live objects. This would allow display of objects by name rather than by address. Another suggestion is to allow the user to modify object values interactively during a breakpoint. A third idea is to allow program execution to be interrupted by a particular keystroke combination.

The MOOD technique requires some cooperation from the program being debugged, but the other side of that coin is that the capabilities of the approach are limited only by the imagination of the programmer.

The techniques embodied in MOOD were described in "Debugging and Instrumentation of C++ Programs" by Martin O'Riordan, then of Glockenspiel, in the Proceedings of the 1988 USENIX C++ Conference.

Copyright © 1991, Dr. Dobb's Journal