The Debugger, MacApp,
and Incremental Linking

By Ronald G. Parsons, Donoho Design Group, Inc., Austin, TX

In the Beginning

Steve Jasik has recently released a new version of The Debugger, Jasik Design’s answer to those who want even the kitchen sink in a source level debugger. The debugging and disassembling aspects of this program have been discussed before here (MacTutor, April 1987, p. 13) and elsewhere (MacWEEK, September 15, 1987, p. 22). In this article, I will concentrate on two new aspects of The Debugger, an incremental build system which greatly reduces the time required for the compile-link-test cycle, and some features added to facilitate debugging in an object-oriented environment - specifically MacApp®. These new features include:

• The ability to “step into” MacApp methods at the source level.

• The addition of an “Object Inspector.”

• The capability to do WriteLn’s to the -Notes- window of The Debugger.

• A procedure entry/exit trace window.

The Debugger provides at least partial solutions to two problems every MacApp developer faces. A MacApp program must be linked with most of the MacApp libraries each time a change is made to the source code and the application rebuilt. Since these libraries are large, even a small MacApp program may require a minute or two on a Mac II for the linker to do its thing. A new feature, the Incremental Build System (IBS), has been added by Jasik to reduce to nearly zero the time required to link after an incremental change.

The Incremental Build System requires a Mac with at least 4 Mb of RAM. It is available only with the Universal Version (which is required for the Mac II and SE/30). A Quick Reference card is now provided for The Debugger. This is a very handy document (four pages of small type) and is concise synopsis of its features.

The Thrill of Debugging

Incremental linking using IBS really shines where a small set of routines need a number of tweaks with debugger sessions in between. Because the MPW editor is not language sensitive, the programmer must tell IBS manually what modules (procedures or functions) have been changed since the last master build using the MPW tool make. Telling IBS that a module needs incremental building is as simple as selecting the name of the changed or new module and selecting a menu item in the MPW shell. Once you’ve told IBS that a module is changed, it remembers until the next full make.

To perform an incremental link, you interrupt your running program by pressing Option-and re-enter the MPW shell. After you make the changes to the source, and tell IBS of the changed module(s), choose the PatchBuild menu item in the IBS menu and the source file is re-compiled, and (nearly) instantly re-linked. If the PatchBuild was successful, your program is restarted where it was interrupted.

Stepping into and thru MacApp methods is as straightforward as in a non-object oriented environment. I have had problems with SADE’s stepIntoMethod proc. It would step into a MacApp method but its brakes would fail and would skid along inside the method, finally stopping after perhaps falling into yet another called method. No such failures were observed with The Debugger’s stepping.

“Getting Acquainted” with Pascal MacApp

Jasik’s IBS notes do not have an example of using MacApp with IBS, so this void is filled below. We’ll use a copy of the MacApp Nothing example program from MacApp 2.0b9. I will assume that the source file is in a folder with path

First the correct MABuild parameters must be used. We need .map and .sym files and we’ll be using The Debugger rather than the MacApp debugger so the MABuild command is:

#1

MABuild Nothing 
 -NoDebug 
 -NoAutobuild 
 -LinkMap 
 -Sym 

Now perform the following steps:

• Build the Nothing application using the MABuild command above.

• Choose Create Project from the IBS menu. You will be asked the find the Nothing application. It will be in the .SADE Non-Debug Files folder within the folder

• The next dialog will ask which type of application you are debugging. Of course, we’ll choose “1) is MacApp based.”

• IBS will create the Debugger Startup Info (.dsi) file. A series of GetFile dialogs will be presented. Select a file in each folder that contains your source or MacApp’s source. Your source will be in and MacApp’s will be in Click cancel when finished.

• Next modify the .dsi file by adding the text from the TList_REDEF file in the SIJ_MacApp_Libs folder of The Debugger before the =END statement of the .dsi file. Now The Debugger will be able to find the appropriate source files and be able to display TList objects better. Save and close the .dsi file.

• Now execute Nothing under the MPW Shell.

• Transfer from Nothing to The Debugger by pressing Option- The source of TApplication. GetEvent will be displayed with the call to WaitNextEvent hilighted.

• Use the Side Door to MPW menu command to transfer to MPW. About the only method overridden in Nothing is TDefaultView.Draw so let’s modify that procedure. Change the PenSize command to draw a thicker border, e.g. PenSize(30, 30);. Hilight the procedure name TDefaultView.Draw and choose Add Hint from the IBS menu. This will tell the IBS that you are modifying this procedure so it will link in the new code. Choose PatchBuild from the IBS menu. The link will be almost instantaneous. If there are no errors, the application Nothing will be resumed at the WaitNextEvent trap. Press Cmd-E to resume Nothing. The gray border will now be thicker. Exit back to The Debugger by again pressing Option-

• Use the Side Door to MPW menu command to transfer to MPW. Now insert a Debugger trap as the first instruction in the TDefaultView.Draw procedure, e.g., DebugStr(‘Stopped in TDefaultView.Draw’);It is not necessary to again choose Add Hint as IBS will remember the changed procedures until the next full build. Choose PatchBuild from the IBS menu. Now when Draw is executed, the debugger trap will be caught by The Debugger and the added source line displayed. The application may be resumed by pressing Cmd-E (Exit to Program).

“Getting Acquainted” with C++ MacApp

Using The Debugger with the new C++ headers for MacApp is not much different from the familiar Pascal MacApp. The correct MABuild parameters are slightly different for C++. We will use the translation of the Pascal Nothing example into C++. Rename the source file CPlusNothing.cp so there will be no conflict with the Nothing project in the IBS menu. If there are string constants in your code that will be debugged, the -b parameter must be passed to CPlus and PatchBuild. The MABuild command is:

#2

MABuild CPlusNothing 
 -NoDebug 
 -NoAutobuild 
 -LinkMap 
 -CPlus -b 
 -Sym 

Now perform the same steps as in the Pascal MacApp case with the following changed steps:

• In addition the other .dsi file changes, add the following lines to the .dsi file before the =End line:

=Flags

CPlus = 1;

• Hilight the procedure name TDefaultView::Draw and choose Add Hint from the IBS menu.

HyperText and The Debugger

One of the great features of The Debugger is its use of the HyperText paradigm. Many commands in The Debugger take whatever is selected in its front window as an argument to a command.

For example, assume we are using the Pascal Nothing application and are stopped in the The Debugger after pressing Option-The Object Inspector Menu (this appears in the right of the menu bar as n - <task name>) contains several items useful with MacApp. Select the first item - Object Classes. In the middle of the list will be the lines

TDEFAULTVIEW TVIEW

Select TDEFAULTVIEW. See Figure 1.

Fig. 1. Classes Window

Press Cmd-space. A definition of the fields in TDefaultView will be displayed in a window along with the field data types. See Figure 2.

Fig. 2. Field Definitions

Select Objects by Class from the Object Inspector Menu. On the list you will see TDEFAULTVIEW_@xxxxxx where xxxxxx is the hex address of the pointer to the object. Select TDEFAULTVIEW_@xxxxxx. See Figure 3

Fig. 3. Objects by Class

Press Cmd-space. A formatted display of the fields in TDefaultView will be displayed in a window along with the field data values. See Figure 4.

Fig. 4. Field Values

Its too bad that this window is not read/write so we could make changes to the field values in this formatted view. Changing memory requires calculating the memory address and entering a hex value in another window. Select just the address @xxxxxx. Press Cmd-space and a hex dump of memory at that address will be displayed. See Figure 5.

Fig. 5. Memory Dump of Object Pointer

Since @xxxxxx is a pointer to the object, select the first 4 bytes of the dump, e.g., YYYY ZZZZ, and press Cmd-space. A hex dump of the object will be displayed. See Figure 6.

Fig. 6. Memory Dump of Object

To see the source for a method, select the name of a class from one of the object menus - say Object Classes. Choose Methods of menu from the Object Inspector Menu. Select one of the methods and press Cmd-D. The source listing of that method will be displayed.

To set a breakpoint, select the symbol in front of the source line. Press Cmd-B and the symbol will change to •. A breakpoint will now be set at that point. Breakpoints can be unset by the same process. See Figure 7. To change from a source level display to an assembly listing, Cmd-click on the window.

Fig. 7. Source Listing Showing Breakpoint

After a bit of use, this HyperText paradigm becomes very natural and familiar.

The “Object Inspector”

The Object Inspector consists of several menu items under the Task Name menu.

• Object Classes - shows a list of the object classes (with their superclass) sorted by the name of the class. We used this menu item above (Figure 1).

• Objects by Time - shows a list of known objects sorted by the time of their creation.

• Objects by Name - shows a list of objects and their addresses sorted by the name of the object.

• Objects of - shows a list of objects. The name of the class should be hilighted prior to choosing this menu item or you will be asked to type the name of the desired class.

• Methods of - shows a list of methods. The name of the class should be hilighted prior to choosing this menu item or you will be asked to type the name of the desired class.

For example if TSSCROLLBAR is hilighted in the Object Classes window and Objects of is chosen from the Object Inspector menu, the list in Figure 8 is shown.

Fig. 8. Objects of display

If the first line of that window is selected and Cmd-space is pressed, the fields of this instance of TSSCROLLBAR is shown. See Figure 9 (entire record is not shown).

Fig. 9. Fields of TSSCROLLBAR

If TSSCROLLBAR is hilighted in the front window and Methods of is chosen from the Object Inspector menu, the list in Figure 10 is shown.

Fig. 10. Methods of display

This new set of Object Inspector functions greatly enhance the ability of The Debugger to work with MacApp and Object Pascal programs.

That .dsi File

Associated with each program (or other task) that The Debugger works on is a file named <appName>.dsi. This Debugger Startup Info (hence .dsi) file contains commands relevant to that program. One of the commands, =Source, gives the pathname to the source. The manual states that the single line following the command contains the pathname to the folder containing the source files. Thankfully (although I wasted nearly a day on this) the documentation is incorrect and the =Source command may be followed by multiple lines containing pathnames to the various folders containing the source to your program, including your libraries and MacApp’s libraries.

A prototype .dsi file will be built for you the first time you create an IBS project (no relation to MPW Projector projects) for the program you will be using with IBS. However if you throw away the file (for example, by throwing away the folder where MacApp stores your objects and The Debugger stores its project files), you are not asked again to locate your source files but The Debugger will keep telling you that it cannot locate the source whenever you re-enter The Debugger.

If you do throw away the .dsi file and the other auxiliary files, you should edit the file IBS_ProjInfo kept in the System Folder. It contains a list of the IBS_project files. Delete the line containing the reference to your program. Then IBS will again ask you to locate all the folders containing source and re-create the .dsi file for you.

[Steve has fixed this problem in later versions of IBS so that the deleter project script references the IBS_ProjInfo file.-ed]

Installation

Installing The Debugger can be a little confusing for the first time user. Installation is covered in at least four places in the documentation - a little differently in each. My version came on one diskette in Auto UnStuffit format. That made it very easy to get the files on the hard disk but confusing when the documentation refers to that “Blue disk” or “White disk” I didn’t have. The IBS_Install script instructions are to “Read it and execute it.” That script contains comments directing me to do additional things besides what the script does. The program’s documentation should include a simple step-by-step set of installation instructions to get the new user over the hump of installation and on to useful work.

The Debugger was installed as an INIT because it must load before MultiFinder. That led to playing the INIT order game. After searching for all the places in the documentation giving hints for this game, I found that I must rename Suitcase II to zSuitcase II and uninstall the TOPS INIT. The latter was a real bummer as TOPS is central to my installation. Fortunately, the next release of TOPS (Version 3.0) eliminates the conflict with The Debugger.

Next I tried the “Getting Acquainted” section of the IBS Release Notes using the MPW Pascal example program TESample. All went exactly as described. Unfortunately I decided to revert back to the original source files by throwing away the folder containing the object, application and other files. Upon recompiling and running under The Debugger, I started getting requests to locate the source files. Of course, the problem was that I had thrown away the .dsi file.

[Steve has recently added a set of Debugger Tech Notes to the documentation. Tech Note #0 contains a revised installation procedure, and the intro letter contains a road map to the documentation. -ed]

More Goodies

The Debugger is not just a debugger - it can be a way of life. Included with The Debugger are a set of MPW scripts and tools of general usefulness to the MPW programmer. These tools make using the Mark facility of the MPW Shell much easier. One of the tools will read a selected set of object (.o) files and build a script to create markers to your procedures and functions. Another tool implements a GOTO Def of menu item. Just select the name of a function or procedure and press Cmd-J. The source is opened at the definition of the function or procedure. If you don’t have Debugger Tech Note #4, get it!

Some Remaining Problems

Because of the newness of IBS and object-oriented additions to The Debugger, there are still some rough edges in these areas. Because the MPW Shell editor is not language sensitive, the programmer is required to manually inform IBS which modules are being changed (and this must be done before saving the source file). Steve Jasik is reportedly trying to obtain a language sensitive editor to alleviate this problem.

When debugging a MacApp program, the Stack window will display the methods in the call chain but often the Until Caller menu item in the Go menu complains that it can’t find the calling routine on the stack. This makes exiting a subroutine a little tedious.

There are some problems with C++ that cause The Debugger some problems. The current version of C++ (3.1b1) has some problems which causes single-stepping at the source level to be double-stepping (two instructions at a time). Also the display of the fields of an object is incorrect - the display is based at the pointer to the object rather that the object itself. These C++ problems should be ironed out by Apple and Jasik in the near future.

Conclusion

Getting through the first day with The Debugger was a trying experience. But as I became more familiar with the program, its charms, hidden as they sometimes are, began to grow on me. The Incremental Build System (IBS) does indeed save a considerable amount of time in repetitive compile-link-test cycles. If you keep your source files short, the compile times are not long and the link time insignificant.

The ability to have my source files in front of me while debugging is great. SADE provides this as well, but SADE seems ponderous compared to The Debugger.

The Object Inspector Menu provides a convenient way of inspecting MacApp objects and their fields. If only the object/field display windows were read/write.

I have only begun to discuss the features of this program. Rather than trying to be all inclusive, I have concentrated on two aspects - Incremental Linking and debugging with MacApp. The Debugger has such a vast set of capabilities that it may not be the debugger for everyone or for every situation. But there are times when only Jasik’s The Debugger will suffice. For those cases, let’s hear it for The Head Nose.