New Debugger
Volume Number: 3
Issue Number: 4
Column Tag: Nosy News
A New Debugger for the Mac 
By Steve Jasik, Famous Mac Guru, MacTutor Contributing Editor
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!