A New Debugger for the Mac

By Steve Jasik, Famous Mac Guru, MacTutor Contributing Editor

Introduction

After 6 months of hard work I was gratified to see the positive reactions of fellow programmmers who stopped off at the Mactutor booth (at MacWorld in SF) to watch my demo of "The Debugger". Had the reactions been any more positive (or lethal?), we would have needed an on-site field hospital for the treatment of blown minds! I was demoing "The Debugger" on a Big Picture by E-Machines, and the problem program (the one being watched by "The Debugger") was running on the Mac screen. I should have a similar setup available for the Micrographics monitor by the time you read this.

Why and How

The current version of TMON has been with us since May 85, almost 2 years (the 585 in V2.585). Given that they didn't seem to be doing much to improve it, I started work on a debugger. I considered this a natural extension of MacNosy.

One of my objectives was to use the standard Macintosh interface. My first task was to figure out how Switcher worked. Then "The Debugger" could run in its own Heap Zone above BufPtr (the Last Byte Address of memory that an application may use). With Nosy and the Switcher internal documentation I was able to disassemble Switcher and understand its LaunchSubTask procedure. As it is a non-trivial exercise, I'll leave the details for some other article. If you can't wait, disassemble RunDbgr, which Launches "The Debugger" into its Heap Zone.

Some Goals

A debugger can be viewed as an extension of a Problem Program (PP). It must be able to interactively display information about PP's state, change the environment, and create opportunities for transfers of control so the user can inspect the PP's behavior.

A primary goal is to present information in formats that are "natural" to the PP and allow us to easily recognize any underlying patterns.

Another goal is to take advantage of the Mac interface so a user of "The Debugger" can select an item to be inspected in detail by clicking on it and issue the command "show me the structure of" the selected item. In Nosy and "The Debugger" this is implemented as "Cmd-space", but more about this later.

Fig. 1 System Globals De-Mystified

The above goals are desirable for any debugger, but one that runs on the Mac needs to take into account that the Mac is not a mainframe. There is no clear separation between the PP and the Mac OS. Stated another way, you are "in bed with the Mac", and any false move may be dangerous to your health. The primary reasons for this situation are the complexity of the Mac interface, the lack of memory protection, and the lack of validation of parameters to Trap calls. Other than time and experience, which bring understanding, little can be done about the complexity of the Mac interface. The lack of memory protection can be solved by an add-on hardware board or chip, but most of us will have to live without this protection for a while. The lack of validation of Trap parameters can be eliminated during the debugging phases of a program by applying the Trap Discipline program as implemented by Steve Capps or as available in the various debuggers.

Given all of the above, I created the slogan "Beyond Discipline, Into Bondage", and set out to implement it in "The Debugger" in a way that would automatically place a larger set of constraints on the PP. "The Debugger" tries to catch a larger class of errors before the program runs amuck and forces the programmer to find a suitable part of his body to scratch to stimulate mental activity.

Some of the other goals are that "The Debugger" run on machines with a 68020 CPU chip (present and future), and that it take advantage of bigger and multiple screens as they become available.

Displaying Information in a Human Readable Format

"Inside Macintosh" uses Pascal to describe the variety of data structures which are part of the Mac system. I first created the command, "Fields of" or " Cmd-?" to display the structure of a record name. Taking this concept further, the notation "Type@nnnn" is interpreted by the "Fields of" processor as a command to display the values of the field of the record. In order to avoid excessive typing in "The Debugger", "Fields of" was further extended so that clicking on an address results in a simple Hex/Ascii dump window of the contents of memory beginning at that address. While developing all this, I decided to de-mystify the System globals (the area from $100 to $1400) by displaying them in their natural formats. Figure 1 is a partial display of them. The FCB window shows the results of clicking on "T_FcbsPtr@nnnn". Other structures that you may find interesting to look at result from chasing the "uTablePtr" and "WindowList". See fig. 1, System Globals.

Fig. 2 The Register Display

The Register Window

Central to any Debugger is a display of the Machine registers and other interesting quantities. As you will note, not only does it display the values of the Address and Data registers in hex, but also the value of the address pointed to by the Address registers, and the values of the Data registers in Ascii. I added a display of "curPort", the current drawing port to the window, as we tend to occasionally draw to the wrong port. See fig. 2, Register Display.

The Stack State

Somewhat more interesting than the Registers display is the state of the Stack. It gives us an idea of what the program was attempting to do when an error occurred. The "=nnnn" in the leftmost column is the machine address at which the call occurred. Selecting it, and pressing "Cmd-D" will bring up a display of the procedure, and position it to the point of the call. The other columns contain the name of the calling routine, the name of the called routine, the address of the stack frame, and the size of the local stack frame. This last number is useful for finding "piggy" routines. They have large local activation records, which may contribute to stack overflow. Note that I use a proprietary algorithm to generate the display that does not involve "chasing" A6. See fig. 3, Stack Frame.

Fig. 3 Stack Frame

Asm Windows

Ideally, one wants to debug a program by looking at a display of the source code. In the current state of the Mac world you can only do this with LightSpeed™ Pascal. Further-more, we don't have source code for the ROM, which was coded in assembly language. "The Debugger" can display a disassembly window in two formats. The first is the standard Nosy format. The second, used in Step mode, leaves an execution trace in the window.

In Figure 4, the numeric fields are (left to right):, the proc rel address of the procedure, the mrs (mode, reg and size) of the instruction, the ea (effective address) of the instruction, and the contents of the ea prior to execution of it. By displaying the data this way, we gather information in one window, that one would have to create many windows to observe. "Observe" windows are not implemented in "The Debugger" as of this writing, but they are high on my to-do list. Other things you may notice about the Asm windows are that all referenced procedures have names, not just the ones in the same segment, and that where data might be an ASCII character, the equivalent is listed on the same line. The line that is about to be executed is hilited.

To change the program counter, one may hilite a line (or an address) and then select the "Set PC" command. Breakpoints are indicated by a • in column 9 of the window. See fig. 4, Asm Window.

Fig. 4 The Asm Window

WatchPoints and ROM Bkpt's

A watchpoint is an area of memory that you want to monitor to find out who is modifing it. In order to do this in software, a debugger must check the area being watched after the execution of every instruction. In Macsbug (SS command) this slows program execution by a factor of 50 to 100. This has a number of undesirable side effects. The mouse and the keyboard are unusable. Also, it is so slow that one sets a watchpoint, and takes a lunch break. This tends to limit the usefulness of the command, as one lunch per day is sufficient for most of us!

I managed to implement watchpoints in such a way that the slowdown is by a factor of 4. This eliminates the undesirable side effects. Thus, the command becomes much more useful in a wider variety of situations.

Breakpoints are a normal part of every debugger. On the Mac debuggers, they are implemented by saving the instruction at the breakpoint and replacing it with a TRAP instruction. When the TRAP is encountered, one ends up in "The Debugger". While one cannot breakpoint into ROM in this sense of the word, one can run the program in a fast step mode until the desired location in ROM is reached. This is what "The Debugger" does when one executes the Go "Until PC =" command.

Fig. 5 The Trap Call Window

A Bit of Bondage

On "real" machines, where much of the arithmetic is done in floating point, it is standard practice to "background" or preset memory to some suitable quantity whose use in a calculation will cause an interrupt. This presetting quickly flushes out the use of variables prior to their definition. "The Debugger" optionally presets stack frames of procedures on entry. This, and other advanced features, help you find programming errors quickly.

Out to Lunch Programs and Jump Tracing

One of the things that makes debugging on the Macintosh difficult are programs that grab an address from the stack or some other place and jump off into the wild blue yonder. Reconstructing the chain of events that led up to this abberent behavior is a non-trivial task. On machines with a 68020 CPU help is at hand in the form of a Trace mode that interrupts only on change of flow. I have implemented a Jump tracing mode for such situations which keeps a record of the last 10 jumps that the program took, and displays it on entry to "The Debugger" in the '-Jumps-" window.

Trap Intercepts

Rather than select Mac trap calls to be intercepted by their trap number or range, "The Debugger" lets you do it by suite, and name within the suite. A suite is a related set of trap calls. You may independently select to break on combinations of entry to, exit from, user or all calls to a given Aline trap. In addition, the parameters of the trap call are displayed in their "natural" format in the "-Trap Call-" window. An alternate way to set or clear a trap intercept is hilite a trap name (underscore optional) and select the "Set Intercept" or "Clear Intercept" commands. See fig. 5, Trap Call Window.

Heap Dump

What's new in my Heap Dump? For one thing, I recognize a few more heap object types, such as patches and TeRecords. The other is that in columns 4 to 12 there is a code of the form "xx@nnnn" that you can click on to bring up a structured display of the block's contents. Note that Cmd-shift-space brings up a Hex/Ascii memory dump window. As the display is text based, you can search it with the Find command, etc. Also: a bullet in column 1 marks a locked block, and a blank in column 2 marks a free block. See fig. 6, Heap Display, followed by fig. 7, showing a text edit record contents.

Fig. 6 The Heap Display

Set Mem Size and Switcher problems

Does your program blow up when it runs in 400K or some other memory size under Switcher? The message you get from Switcher that your program was terminated by a System Error is not very helpful! So I added the "Set Mem size" command so that you could easly test your program under control of "The Debugger". You use the command prior to launching the PP in "The Debugger". The command was put into immediate service when I spent a day chasing down memory-related blowups in Nosy running in a 500K partition.

BreakPoints - Any Time, Any Place

"The Debugger" allows you to specify an "unlimited" number of breakpoints (the Surgeon General has determined that Breakpoints are subject to memory limits). Another neat thing I did was to patch into _LoadSeg and _UnloadSeg so you can set a breakpoint anywhere in your program without having to worry about the segment being in memory. This is useful for your own programs, and doubly useful for cracking heavily protected programs that have code to disable debuggers. You can set a breakpoint at a particular location by bringing up a display of the procedure containing the location, hiliting the entire line or just the address, and selecting "Set Bkpt at". Another way to set a group of breakpoints is to select a list of names in the "-Code Blks-" browser window and select the "Set Bkpt at" command. This will cause the program to break into "The Debugger" on entry to the procedure.

Fig. 7 TeRec Structure Displayed

GNE Intercept

TMON has a command called "Trap Signal" which lets you enter it on a GetNextEvent call. My implementation lets you type "option-\" to enter "The Debugger" on exit from a GNE call. You can also select to break on a specific event type. For example, you can study how a program processes window activate events. This command is a special case of conditional Breakpointing.

Miscellaneous Features

Like Nosy, "The Debugger" has an on-line help facility, and full text file handling facilities (open, close, delete, edit and search). It has commands to re-Launch an application, boot the system, and unFreeze the Mouse. Last but not least, it shares the Tables menu with Nosy, so the IM record definitions, Trap calls, error numbers etc are on-line.

The Future of The Debugger

Unfortunately I cannot code features into a program as fast as we can think of them. There are a number of features which are planned for "The Debugger", but are not coded yet. By the time you read this, the following features should be added to it:

* An Observe window to watch the values of variables;

* A calculator window;

* Conditional Bkpt's with Print clauses;

* Trap discipline;

* Facilities to record the values of variables;

* Ability to feed it files of user defined record types;

By this summer, in cooperation with some of the compiler makers, true source level debugging should be available on the Mac.

Nosy - Present and Future

Nosy is up to V2.55. I've cleaned up the handling of ".map" files so they can serve as input to "The Debugger". I've also enhanced case statement recognition, including code to recognize and process case statements generated by LightSpeed™ C. More significant to most of you is that Nosy will now have a real manual!! Nosy and "The Debugger" will support the SE and the II. For further details on updates and ordering information, check out my advertisments in MacTutor in this issue and over the next few months.

Late News Flash!

The Debugger now reads the symbol table in a LS C project file. One may transfer directly from LS C to the debugger, launch the project file and have access to all the procedure names and global variables in the program. Thanks Think!