Using Macsbug to debug Modula-2 Programs

By Tom Taylor, Modula Corp., Provo, Ut., MacTutor Contributing Editor

Developing a Mac application is not an exercise in trivial programming. With four or five hundred toolbox routines at the programmer's disposal, writing a Mac-like program can be somewhat frustrating. With no debugger available, the MacModula-2 programmer is usually baffled and angry when his program bombs with ID=02 or some other bomb box.

Although MacModula-2 does not come with a debugger, a machine-language level debugger by Apple can be used by the Modula-2 programmer. MacModula-2 traps most runtime errors such as range violation, integer, cardinal, real, and storage overflow, among others. The toolbox, however, may not be so forgiving. Passing bad parameters or calling routines in the wrong order can cause the infamous bomb box to appear. Fortunately, Apple's debugger can be very useful when debugging a Modula-2 program riddled with toolbox calls.

MacsBug

In order to debug a program at the machine-code level, it is necessary to obtain a debugger. Apple supplies a number of debuggers with its Macintosh 68000 Development System package:

• Maxbug - a full-screen debugger for 512k Macs.

• Macsbug or Midibug - an 8-line debugger for 128k Macs.

• Termbug A and Termbug B - debuggers that display their information on an external terminal plugged into the modem or printer port.

I use Maxbug because of its 40-line display and the fact that it is the only debugger (of the ones mentioned) that actually displays the toolbox trap names during operation. The terminal-based debuggers come in handy once in a while because they allow the user to print the heap on the ImageWriter. This article and its examples will use Maxbug. Any one of the debuggers mentioned can be found in the following places:

• From Apple's Macintosh 68000 Development System package.

• From Compuserve. The debuggers have been uploaded to the Macintosh Developer's section.

• From someone who has Apple's Software Supplement.

It would also be extremely helpful to obtain and read a copy of the documentation that describes the MacsBug debuggers. Before installing the debugger, you should install the "Programmer's Switch" that came with your Mac. This switch installs in the lower-left-hand side of the Mac. The button closest to the front reboots the Mac and the rear button generates a non-maskable interrupt. Pushing this button without the debugger installed generates a bomb box with ID=13. With the debugger installed, it simply places you in control of the debugger. Regardless of which debugger you wish to use, you must copy it to your boot disk and name it Macsbug. Whenever you boot with this disk, the debugger will automatically be installed (note: this means that after copying the debugger to the boot disk and renaming it, you must shutdown and re-boot in order to install the debugger). If you have not installed your own startup screen on your boot disk, you'll see a "MacsBug Installed." message under the "Welcome to Macintosh" bootup message (see figure 1). If you have installed your own startup screen, no message will be displayed but the debugger will still be installed.

Figure 1. The startup screen with MacsBug on the boot disk.

If this is your first experience with the debugger, wait till the Finder has come up and the disk drives have stopped spinning and hit the debug button on the side of the Mac. If you are using Maxbug, the screen should clear and display something like figure 2. If you are using Midibug, you'll see figure 2 on the bottom part of the screen. Finally, if you are using one of the terminal debuggers, you'll see figure 2 on the external terminal. Generally, whenever you enter the debugger, all of the registers are displayed and the next line to be executed is disassembled. The debugger, à la conventional (i.e. pre-Mac) programs, displays a ">" prompt and waits for the user to enter a debug command. There are many commands that can be entered here. For starters, though, enter a "G" (in these debug examples, the bold type highlights the commands that should be typed by you, the user). The screen will display the desktop again and the Mac will resume normal operation.

Figure 2. 1-Disassembled listing of next line to be executed, 2-Current stack pointer, and 3-Debugger prompt.

There are at least four ways to enter the debugger:

• Assemble the debugger trap ($A9FF) into an assembly language program.

• Perform some operation that generates a Macintosh serious error that would normally put up a bomb box.

• Press the interrupt button on the side of the Mac.

• Enter commands to the debugger that cause a program to enter the debugger when certain conditions are met.

Since the debugger "catches" the Mac system errors (at least most of them!), I almost always have the debugger installed. This allows me to continue operation without having to reboot. More on this later... Some programs will not work with the debugger installed. These programs include those that use the alternate screen buffer. Apparently the debugger and the alternate screen live in the same area in memory. Since the debuggers chew up a lot memory, some big programs won't run on a 128k Mac. The MDS Edit program, for example, hangs on a 128k Mac with the debugger installed. Sometimes I want as much memory as possible in Switcher so I remove the debugger by renaming it, and rebooting.

A Debug Example

When a MacModula-2 program dies with some system error, I usually perform the following operation in order to narrow down the location of the bug. The debugger is capable of printing out the name of each toolbox routine whenever the routine is called. Furthermore, the debugger can limit the printing of the toolbox names called from a certain range of addresses. This is an important feature. It allows us to only see the toolbox calls made from our Modula-2 program and not calls made by the toolbox itself. From now on, I'll call a "toolbox call" a trap or A-trap. Toolbox calls are not called directly as subroutines. Instead, each toolbox routine is assigned a 16-bit value where the first four bits are 1010 (or a hex A, hence the name, A-trap!). No legal 68000 instruction begins with the 1010 bit pattern. Whenever the 68000 processor hits one of these words that begin with 1010, it generates a '1010' interrupt and traps the interrupt to a specific address. At that address there is a routine that uses the last 12 bits of the trap to determine whether the trap is a ToolBox trap (parameters passed on the stack) or an O.S. trap (parameters passed in registers) and uses 8 of the bits as an index into a trap dispatch table. By using this technique, Apple has cleverly extended the 68000 instruction set and made a way to patch various routines easily. The debugger can perform many operations with the different traps, some of which will be discussed later.

The most common error on the Mac seems to be the address error (ID=02). This occurs whenever the 68000 tries to perform some word or longword operation with an odd-address. The second most common error is an illegal instruction (ID=03). Generally when you get this error, your program has jumped off somewhere in memory and attempted to execute data or garbage. In order to try out the debugger, let's create a simple Modula-2 program (figure 3) that generates an address error and examine what happens when the program is executed.

Figure 3. A Modula-2 program to generate a Macintosh address error

When the program in figure 3 is executed, it will generate an address error and invoke the debugger and display something like the first part of figure 4 (everything up to the first ">" prompt). The Modula-2 program crashes because it sets up a pointer equal to 1 and tries to access a word variable at that location (remember: accessing a word at an odd address is a no-no on the 68000). Figure 4, arrow 1, shows how the debugger prints the offending address (00000001). By examining the dumped registers, we can generally determine which register held the bad address (see arrow 2). The instruction that caused the address error is usually in the immediate vicinity of the current PC. By using the debugger's disassemble command (IL), I start disassembling the code 10 bytes in front of the PC (see arrow 3). That gives a nice window of instructions from where the error occurred. Notice how "PC" is displayed right in front of one of the instructions. That instruction is the next one to be executed. The instruction immediately preceding the "PC" is the instruction that caused the address error (see arrow 4). The instruction tried to access the contents of the word of A0, or 00000001, an odd-address. To get back to the finder without rebooting, simply use the Exit-to-Shell (ES) debugger command.

Figure 4. Debug display of Figure 3's execution

MacModula-2 Internals

Before moving on to a more complicated and more realistic debugging example, a few words on the internals of the MacModula-2 interpreter would be useful. As you are probably aware, the MacModula-2 compiler does not generate 68000 native code. Instead, the compiler generates an intermediate code called "M-Code." The Modula-2 program is responsible for the following:

• Loading .LOD files and program overlays from disk into memory.

• Interpreting each M-Code by executing a number of 68000 instructions that represent the function of the M-Code.

• Providing the necessary interface between Modula-2 and the Mac's ToolBox.

• Provide terminal handling routines for the Terminal and InOut modules.

This article is most interested in the interface between Modula-2 and the ToolBox. In MacModula-2, there are two different ways to call ToolBox routines. The first, and cleaner of the two ways, is to simply import the desired ToolBox routine into a program. When the M2 Linker links a program that makes ToolBox calls, it generates a CX (Call External) M-Code to a hardwired module and procedure number (there is a specific module number for every ToolBox manager and a distinct procedure number for every procedure in each manager). The second method of calling ToolBox routines involves "cutting and pasting" ToolBox code procedures into a source module. Each of the code procedure has the module and procedure numbers hardcoded right into the routine. These numbers are the same that the M2 Linker assigns while linking modules using the import method of calling ToolBox routines. In either case, when the Modula-2 interpreter executes a CX M-Code and the module number belongs to a ToolBox manager, a number of table lookups are made and the interpreter jumps to an appropriate glue routine. There is a glue routine for every ToolBox trap supported by MacModula-2. The glue routine is responsible for moving parameters off of the Modula-2 expression stack and putting them on the Mac's hardware stack (or in registers if the trap is an O.S. trap) and calling the correct ToolBox trap. If the ToolBox trap is a function, then the glue routine must pop the result off of the Mac's stack and push it on the Modula-2 stack. I mention this because it will help you to understand any disassembled code immediately surrounding most traps found in the Modula-2 interpreter.

This next example shows how to trace the various ToolBox calls made from Modula-2 and help isolate the source of errors. The following example is a simple program that puts up the apple menu and allows the use of desk accessories (see figure 5). This program has a built-in bug and the goal of this example is to find the bug. After launching the program and opening a desk accessory, clicking inside the accessory on the desktop causes the program to die with an address error. Here are the steps necessary to debug this program:

• Execute the program in figure 5 and open a desk accessory (the calculator, for example).

• Position the mouse cursor over the calculator's close box and press the interrupt button on the side of the Mac.

• At this point, we want to tell the debugger to display any Mac A-trap called from the Modula-2 interpreter. In order to tell the debugger to only display traps called from the interpreter, it is necessary to give the debugger the starting and ending addresses of the interpreter's code in memory. The Modula-2 interpreter is written as one code segment. By typing HD 'CODE', the debugger will display heap information about the code (see figure 6).

• The HD 'CODE' command will cause the debugger to print out three lines. We are interested in the middle line. The third field on the middle line is the length (in hex bytes) of the Modula-2 interpreter's code. The fifth field contains an address of a pointer that points to four bytes before the beginning of the code. The actual address of the start of the code is found by using the DM (display memory) command. Typing the '@' character in front of an address or register causes the debugger to treat the address or register as a pointer and go indirect through that address or register. In this case, I typed: DM @CC18+4. This means, "Get the longword contents at the address CC18 (which happens to be CE8E), add 4 to it, and display 16 bytes of memory at that location." The calculated address in this example, CE92, is the beginning of the Modula-2 interpreter's code.

• The next step is to use the debugger's AT (A-trap Trace) command to tell the debugger to trace all traps called from the Modula-2 interpreter. The AT command takes up to four parameters. These parameters are: starting trap number, ending trap number, starting address, and ending address. All traps with a number between the starting trap number and the ending trap number called within the starting and ending address with be displayed.

• Execution is continued by typing G. Using Maxbug, the screen will really flicker while the debugger traces the traps and switches between the normal and debugger screens. Since we are trying to debug the situation when the mouse is pressed inside a desk accessory, go ahead and press the mouse (and hold it until the program bombs with an address error). Look at the address of the disassembled line immediately after the address error message. If the address is in the 400000 range, then the program died in a ROM ToolBox routine. Look at the last trap printed out. This routine is the one suspected of causing the crash. Those using a debugger other than Maxbug will only see trap numbers and not trap names. You'll need to look up the trap name in one of the many trap lists that exist (like the one in the back of Inside Macintosh).

• At this point, it's time to look back at the Modula-2 source code (figure 5) and examine the parameters to the SystemClick routine. After a quick peek, it's obvious that a bad parameter was passed to the routine.

MODULE ToolBoxCrash;

  (* This program simply allows the
     use of desk accessories.  This
     program will probably bomb in the
     SystemClick() routine at the end
     of the program. *)

  FROM MenuManager IMPORT
    menuHandle, NewMenu,
    AddResMenu, InsertMenu,
    DrawMenuBar, MenuSelect,
    GetItem, AppendMenu,
    HiLiteMenu;

  FROM MacSystemTypes IMPORT
    Str255, LongCard;

  FROM Strings IMPORT
    StrModToMac;
  
  FROM DeskManager IMPORT
    SystemTask, SystemClick,
    OpenDeskAcc;
  
  FROM EventManager IMPORT
    EventRecord, GetNextEvent;
  
  FROM WindowManager IMPORT
    FindWindow, WindowPtr;
   
  VAR
    menu : ARRAY [0..2] OF menuHandle;
 
  PROCEDURE SetUpDeskAccs;
    VAR
      appleHeader : Str255;
  BEGIN
    appleHeader[0] := 1c;
    appleHeader[1] := CHR(14h); (* apple mark *)
    menu[0] := NewMenu(1,appleHeader);
    AddResMenu(menu[0],'DRVR'); (* add desk acc's *)
    
    StrModToMac(appleHeader,'Exit');
    menu[1] := NewMenu(2,appleHeader);
    StrModToMac(appleHeader,'Quit');
    AppendMenu(menu[1],appleHeader);
 
    InsertMenu(menu[0],0);
    InsertMenu(menu[1],0);
    DrawMenuBar;
  END SetUpDeskAccs;

  VAR
    event : EventRecord;
    window, badWindow : WindowPtr;
    menuID : LongCard;
    accessory : Str255;
    refNum : INTEGER;
  
  CONST
    everyEvent  = -1;
    mouseDown   = 1;
    inMenuBar   = 1;
    inSysWindow = 2; 
    
BEGIN
  SetUpDeskAccs;
  LOOP
    SystemTask;
    IF GetNextEvent(everyEvent,event) THEN
      IF event.what = mouseDown THEN
        CASE FindWindow(event.where,window) OF
             inMenuBar:
                menuID.r := MenuSelect(event.where);
               IF menuID.h = 1 (* Apple Menu *) THEN
                  GetItem(menu[0],menuID.l,accessory);
                  refNum := OpenDeskAcc(accessory);
               ELSIF menuID.h = 2 (* Quit Menu *) THEN
                 IF menuID.l = 1 THEN EXIT END;
              END;
              HiLiteMenu(0);
         | inSysWindow:
             (* Pass a bad window ptr here! Change
                  badWindow to window to make the program
                 work correctly.
              *)
             SystemClick(event,badWindow); 
        ELSE
        END;
      END;
    END;
  END;
END ToolBoxCrash.

Figure 5. Modula-2 ToolBox debugging example

Figure 6. Tracing a Modula-2 program's ToolBox calls

Although this method of tracing and isolating bugs may seem difficult, I can assure you that it is worthwhile and much simpler and faster than peppering a program with "Print" debug statements and recompiling. In fact, I have debugged many, many Modula-2 programs that people have sent me without ever looking at the source code. Even though this article has only brushed the surface of debugging techniques and how to use the debugger, hopefully it will give the MacModula-2 user enough confidence to try some low-level debugging and gain a better understanding on how the Mac works.

NEW BOOK FOR MODULA-2!

A new book has been released by Prentice-Hall that will be particularly important to Modula-2 users. It's called "Macintosh Graphics in Modula-2" by Russell L. Schnapp. This is the first and at present only book on Modula-2 on the Mac. At first glance, the book appears to be very well written, organized and illustrated with Modula-2 code on nearly every page. This should be a must buy book for the Modula-2 community. Included in the advanced section are routines for 3-D graphics, shading of 3-D objects, hidden edge routines, rotations, animations and finally, a micro-draw graphics editor. The book has a classroom flavor with exercises and necessary mathematical background where it is warrented. The listings are very readable and appear to be highly valuable, especially the "mini-mac draw" application. The copyright date says 1986 but I'm looking at a copy in my hands in 1985. We give this one a thumbs up.