Debugging Techniques and TMON Review"

By Paul Snively, Columbus, IN., MacTutor Contributing Editor

I was just reading my Volume 1, No. 4 MacTutor and came across William Gladnick's letter asking about tips, utilities, and debugging techniques. OK, I'll bite!

MacsBug Snoops the ROMS

As far as useful utilities go, first, get a 512K system. Then get MacNOSY and TMON (the latter is from TMQ software). These, plus a good assembler (MacASM, in other words) are all that you really need to do serious Mac hacking.

As for tips, here's one: the Mac ROMs are buggy, and nearly everyone knows it. What's not so obvious is how to use MacsBug to trace through the ROMs step by step (rather than treating the A-traps as a single instruction). Wouldn't it be nice to be able to trace one instruction at a time while in a ROM routine? OK, here's how: write your application (I assume that you are using one assembler or another). The first instruction should be:

 LABEL   BRA   LABEL

followed by your program. Assemble the program in the usual way. Install MacsBug in your system. Double-click your program's icon. The system will seem to hang, since you told it to BRanch Always to LABEL, which is where the branch is. In other words, your program is in an infinite loop. Press the interrupt button on your Mac. MacsBug will be entered with the PC pointing to your BRA instruction. Bump the PC by two to point past the BRA. Now start tracing your program.

How to Trace the ROM Routines

As you are tracing or stepping through your code with MacsBug, the disassembly will eventually say something along the lines of "OSTRAP A219" or "TOOLBOX A912" or what have you. STOP! DO NOT TRACE OR STEP! Now, change the value in A7 downward by six bytes. In other words, if A7 is now 00123AC7, change it to 00123AC1. This is to simulate the stack setup caused by the 68000 during exception processing.

Now, look at the current PC value. Let's say it's 00004E56. Store this address at A7+2 using the SM command, like this:

SM 00123AC3 00 00 4E 56 

Now type PC 401018. You may now continue tracing or what have you. Essentially, you have done manually what the 68000 would have done automatically upon encountering the A-trap. 401018 is the address of the Macintosh A-trap dispatch routine. Observe the code as you trace through it; it's quite interesting. For example, the main difference between OSTRAPs and TOOLBOX traps is that for OSTRAPs, which require an I/O buffer address in A0 and return a status code in D0, A0 and D0 must not be saved on the stack across the actual code. Apple accomplished this by setting bit 11 in all of the TOOLBOX instructions (in other words, the second hexadecimal digit of a TOOLBOX trap will always be at least 8). The dispatch code at 401018 examines that bit to determine whether or not to save A0 and D0 (and possibly some other registers) on the stack.

More important, you can watch as the dispatch code determines via a lookup table where to go in the ROMs, and you can trace through those high-power ROM routines that we've all come to know and love. Now you can see for yourself exactly how a window is opened, or what have you.

The ability to trace through the ROMs, coupled with MacNOSY's capability of outputting labels, as opposed to addresses, makes for a relatively simple way of learning how the Mac works right down at the nuts and bolts level - which is right up MacTutor's alley, right, guys?

May all of your hacking - er, excuse me, I mean programming - be bug free!

TMON Thoughts

Some of you may have seen TMQ Software's ad in MacTutor lately. They're pushing a product called TMON, which at first made me laugh - TMON was the name of the first machine language monitor I ever actually laid my mits upon; it was for my (at the time) tape based Model I TRS-80. You can see why I laughed.

Nevertheless, TMQ promised some interesting things, like tracing ROM and setting up to seven breakpoints. Also, they claimed that TMON was a multiple-window monitor/debugger. Just the idea that a debugger could be multiple window boggled me. The thing must be huge. Especially if it can disassemble, do hex dumps, heap displays, register displays, and so on simultaneously.

The price looked pretty reasonable for all of this: the ad asked for $100.00, which is less than I paid for MacASM, my assembler of choice. I finally broke down and ordered TMON from TMQ. It arrived a few days after I ordered it; if you're willing to pay for it, TMQ will ship UPS blue label, which is how I prefer to work.

After using TMON and configuring it and reconfiguring it and debugging some of my own code and tinkering around with some code that I didn't write, I can make the following observations.

Love at First Byte

First, if you don't already own a copy of TMON, run, don't walk, to get your checkbook and order it now. If you are a serious developer (and if you are reading this, chances are pretty good that you are) you should be using TMON. Use TMON once and you'll never boot MacsBug again. I promise.

The ads really don't do it justice. They don't tell you about the interactive assembler/disassembler; they don't tell you about the fact that dump and disassembly windows can be "anchored" to registers and are continually updated; they don't tell you that TMON allows access to any online resource file; they don't tell you about the customizable user area; they don't tell you about the sophisticated label support, or the screen buffering, or the rich implementation of interrupt button functions... The list goes on.

Think of TMON as MacsBug and MacNosy combined, with some things thrown in that neither MacsBug nor MacNosy was intended to do. To be fair about it, since MacNosy is a disassembler and not a debugger, there are some features that MacNosy has that TMON doesn't. I recommend both of them if you are serious about Mac programming.

TMON's fast window system will impress you, as will its implementation of menus. It takes a little getting used to; both windows and the menubar are handled a little differently from "normal" Mac windows and menus.

Mouse Unfreeze

The menus are Dump, Asmbly, Brkpnts, Regs, Heap, File, Exit, GoSub, Step, Trace, Options, Num, User, and Print. Another feature that TMON implements via a command keystroke is called Mouse Unfreeze. Yes, you read right - if your program crashes and your mouse freezes up but the keyboard is still listening, you can unfreeze the mouse. Wild stuff.

Dump opens a window which is initially a dump starting at address 000000. There is a blinking cursor on the first line. As long as the cursor is on the first line, the address can be changed. You can type in any expression, label, or register to anchor to (as well as a special virtual register called V). The window will be instantaneously updated to show the new dump. More importantly, if you anchor to a register (say A0), whenever the contents of A0 changes the window will be updated to reflect the change. You won't believe how useful this is until you see it.

Disassembler Anchored to the PC Counter

'Asmbly' is the interactive assembler / disassembler. When you open this window, you get a disassembly starting at 000000, which doesn't make much sense, since there is no valid code there. You'll probably want to anchor the disassembly window to the PC. Like the dump window, when you anchor the disassembly window to a register it gets updated every time the register changes. Anchoring the disassembly window to the PC causes the window to be updated every time you step, trace, gosub, or exit to the program (actually, since exit actually transfers control to the program, the window will not be updated unless control returns to the monitor).

TMON normally displays A-traps as labels, not numbers, although this can be changed in order to conserve space. TMON also supports user-defined label tables. The TMON master disk includes a file called System.MAP which is a label file of all of the low memory equates on the Macintosh. This MAP file can be loaded into TMON so that features of TMON that support labels (nearly all of them, in other words) can now refer to low RAM areas (with labels like CurApName and so on) by name instead of address. This aspect of TMON, unfortunately, requires 512K.

TMON includes sophisticated customization support that allows you to fine tune TMON to your needs. TMON is quite capable of running on a 128K machine, and contrary to what you might think, it does not have to be hopelessly crippled in order to do so. I can use A-trap names and, with a compressed screen buffer of 4K, do some meaningful debugging. A 512K Mac sure would help, though.

TMON has an alternate register save area. This is interesting. You can come close to a routine that you think will crash, save the registers, execute the routine, and if it crashes (an exception lands you back in TMON), you can reload the registers and try again, and so forth. Kind of like being in suspended animation.

We all know that the interrupt button on the Mac is good for something. TMON knows it, too. Pressing the button from an application will get you into TMON, just like it does with MacsBug. However, there are several special-purpose keystroke-interrupt combinations that TMON has over MacsBug.

Pressing interrupt while holding down the command key restarts the monitor. This is considered a drastic step to be taken only when all else fails. This often has the effect of mulching part of TMON. The nice thing is that TMON is constantly checking itself, and if it thinks it's been damaged, it will say so.

Cmd-Option-Interrupt!

If that doesn't work, try command - option - interrupt. This does a really total monitor reset, which makes it definitely last-resort material.

Now for the interesting one. The user area supplied with TMON contains a function called Trap Signal. The manual calls the Trap Signal function a "smart interrupt," which is a pretty apt description. Trap Signal allows you to specify a trap or range of traps to apply this function to, as well as an optional address or address range. Once you've done that, go ahead and execute your program.

Nothing happened, right? You're program should be whizzing merrily along. Now press interrupt while holding down the option key. This activates the trap signal, which won't go into effect until your trap and address range criteria are met. That's why it's called a smart interrupt: it doesn't stop until it hits the right trap/PC location. This allows you to interrupt your program at a specific place rather than going into it blind. A good trap to put a smart interrupt on would be _GetNextEvent, since it tends to be at the main loop of any Mac application.

Trace uses the Trace bit

TMON's trace, step, and GoSub features are very nice and very powerful. TMQ Software saw fit to do what no one else did: they use the trace bit of the status register to force a trace interrupt, which the monitor traps. This is the essence of tracing under TMON. The trace function even allows you to watch as the A-trap dispatcher finds the address of the A-trap's code and executes it. This means that my little note concerning tracing the ROMs under MacsBug doesn't apply here; TMON's trace does it automatically. Step in TMON is exactly like trace except that A-traps are treated as a single instruction. GoSub is like step except that subroutines (executed by JSR or BSR) are executed in full without tracing.

The heap windows are something else. Not only do they show what blocks exist and whether the block is locked, purgable, relocatable, and what have you; they also show what is in the block (to the best of TMON's ability). You can see at a glance which block contains CODE segment number one of your program, which block contains the font that is currently in use, which blocks contain resources pertinent to the application, and so on. You can also examine the system heap in the same manner. A heap window can be made to switch from appplication heap to system or vice-versa by hitting the TAB key (which puts the cursor at the top of the window) and hitting the RETURN or ENTER key.

The file window is extremely useful. It shows the contents of all currently open resource files. For those resources that are in memory, their handle is given. For those that haven't been loaded from disk yet, "Nowhere" is displayed. Resources of any type and ID can be loaded using the standard user area LoadRes utility.

If a window is too limited to show you as much as you would like of what it is you're looking at, you can probably print it with the user area print utility. You can specify dump printing, disassembly printing, file printing, or heap printing. For dumps and disassemblies you must specify an address range. For files TMON needs the resource file number, and for heap prints it needs 0 for the system heap and a non-zero value for the application heap.

There are lots of other handy features, too, such as block moves, block compares, block fills, checksumming of memory, label table support, a very efficient heap scramble, a find utility, the ability to show the application's screen, and the ability to completely reset the system.

User Extensible via MDS

To make matters even better, the author includes the source code to the entire default user area on the TMON disk. The point is that sophisticated Mac programmers can write their own user area utilities that can either replace or augment the ones included with TMON. The source is in MDS format, and a link file is included to link the resulting object code into TMON. Obviously, you must have MDS for this to be of any use. Frankly, I think it'll be a long time before anyone comes up with a way to improve upon TMON's already fantastic user area routines.

That about wraps it up. My idea of an ideal Mac debugging setup is a 512K Mac running TMON. Use the normal default user area, then add in the System.MAP file. This will allow TMON to refer to low memory areas by name (which is handy if you're doing ROM disassemblies in particular). Now you can really debug! Goodbye, MacsBug; hello, TMON!