[Indigo]<Mesa>Doc>Debugger>Debug1.bravo!1

The runtime and debugging facilities differ in their relationship to the user program. When you invoke Mesa.image, it provides the code necessary for your program to communicate with the debugger; it resides with the user program. An optional Mesa Executive serves the function of an executive when the Mesa system is first started (see the Mesa System Documentation for further details). The debugger, however, resides in a different core image which is loaded when called for; it operates with a complete world-swap.

Before a client program can use the Mesa debugger, the debugger must be installed. This operation saves the debugger’s core image. Typing XDebug to the Alto Executive automatically installs the debugger. Other programs may be loaded into the debugger by including their names on the command line. The Debugger now requires a strike font named MesaFont.strike or SysFont.strike. See the Mesa User’s Handbook for further details.

There are several ways of invoking the debugger. One method is to issue the Debug command to the Mesa Executive; this brings you into the debugger, ready to execute a command. Invoking a BCD from the Alto Executive with the /d switch causes Mesa.image to go to the debugger after loading the BCD, but before starting it. See the Mesa User’s Handbook for complete information on various debugging switches. If you wish to enter the debugger at any time (i.e., while your program is running), ↑SWAT interrupts your program. (If you really get in trouble Section 7 contains details on bootloading the debugger.)

In the course of running your program, you may enter the debugger for several other reasons. Your program may generate an uncaught signal, execute a breakpoint/tracepoint that has been placed in your program, or encounter a fatal system error that forces your program to abort (Section 7 contains further details on the messages displayed when entering the debugger in these situations).

The user interface to the debugger is controlled by a command processor that invokes a collection of procedures for managing breakpoints, examining user data symbolically, and setting the context in which user symbols are looked up.

When receiving commands, the debugger extends each input character to the maximal unique string that it specifies. Whenever an invalid character is typed, a ? is displayed and you are returned to command level. Typing a ? at any point during command selection prompts you with the collection of valid characters (in upper case) and their associated maximal strings (in lower case) and returns you to command level. Whenever a valid command is recognized, you are prompted for parameters (Section 3 contains further details on the input conventions). Typing DEL at any point during command selection or parameter collection returns you to the command processor; typing ↑DEL at any point during command execution aborts the command.

When initialized, the debugger creates two windows: the Debug.log window which becomes a record of the debugging session, and a source window which is loaded with the source file when breakpoints are set or the source location is requested. These windows may be manipulated by the window manager which comes with your debugger (see Section 2 for further details).

Interpreting symbols (including displaying variables, setting breakpoints, and calling procedures) occurs in the current context; it consists of the current frame and its corresponding module, configuration, and process. The symbol lookup algorithm used by the debugger is as follows: it searches the runtime stack of procedure frames in LIFO order by examining first the local frame of each procedure (and then its associated global frame), following return links, until the root of the process is encountered.

When you first enter the debugger, the context is set to the frame of whatever process is currently running (i.e., to the Mesa Executive, if you enter via the Debug command; to your program, if it is interrupted or at a breakpoint). There are commands which make it simple to change between contexts (SEt Root configuration, SEt Module context), to display the current context (CUrrent context), and to examine the current dynamic state (Display Stack).

Whenever the debugger needs symbols to display some information, it searches for the original compiler-output BCD before looking for symbols where they were last copied by the binder. Types used, but not declared, within a module are looked up using the same algorithm as in the compiler. If the module containing the original declaration is unavailable, the debugger uses whatever information has been copied into the symbol table of the module using that type.

Once you are in the debugger, you may execute any number of commands that allow you to examine (and change) the state of your program. When you are finished, you may decide either to continue execution of your program (Proceed), terminate execution of your program (Quit), or end the debugging session completely and return to the Alto Executive (Kill). Section 4 contains further details on these commands.