SADE Debugging
Volume Number: 5
Issue Number: 9
Column Tag: Programmer's Workshop
SADE™ Debugging 
By Joe Pillera, Ann Arbor, MI
Debugging In MPW With SADE™
Joe Pillera is a Scientific Staff Member at Bell Northern Research (BNR) in Ann
Arbor, Michigan. Prior to this he was a Systems Analyst at the Ford Motor Company.
He earned his B.S. in Computer Science from Eastern Michigan University, and is now
a Master’s of Computer Science degree candidate at Wayne State University. His
primary area of research is object oriented programming and software engineering.
A good debugger is a programmer’s best friend. One of the serious drawbacks to
MPW (Macintosh Programmer’s Workshop) software development has always been a
lack of a source level debugger (no, I don’t consider MacsBug hexadecimal dumps
debugging!). Until now. Introducing SADE™ - the Symbolic Application Debugging
Environment. This is Apple’s new source level debugger for MPW 3.0 and beyond.
In this article I plan to cover the following:
• An overview of SADE.
• SADE in action - debugging a sample C program.
• A numerical integrator - pushing the SADE script language to the limit.
• Talking straight - the good, the bad and the ugly.
Note that even though this is not a ‘comparison’ article, I will occasionally
mention THINK’s Lightspeed™ debuggers (because of their excellent performance), as
a frame of reference in discussing SADE.
Figure 1. The SADE Menu System
What Is SADE, Anyway?
SADE is not an MPW tool, nor is it physically part of the MPW shell. It is simply
a stand-alone application that communicates with your target program under
Multi finder. As in THINK’s Lightspeed C, this debugger must be operated under
Multi finder, to allow interprocess communication. Two or more megs of memory are
strongly recommended; however, the manual does indicate you can squeeze by with one
meg. The only special requirements to run SADE are:
1. You must be using Multifinder 6.1b7 or later.
2. The (Pascal or C) compiler must be instructed to generate ‘symbol’ files during
program compiles.
One of the more interesting design decisions Apple made was to make SADE appear
almost identical to the MPW Shell. This has both an advantage and a disadvantage: the
advantage is that of instant familiarity to existing MPW programmers; the
disadvantage is that this precludes the use of a user-friendly, animated interface (such
as the debuggers used in THINK’s Lightspeed C and Lightspeed Pascal).
Please refer to Figure 1 for a closer look at SADE’s functionality.
Wade Through Your Code With SADE
The most fundamental operation in using a debugger is setting a breakpoint in the
source code. Because SADE is so sophisticated, there are four ways to do this:
1. Enter the break command from the SADE command interpreter. The syntax (for
debugging a C program) is:
break .()
2. Call the function SysError from within the C code itself. The syntax of this
approach is:
#include
. . .
SysError().
3. Press the SADEKey (Command-Option-).
4. Open a source code file (as read-only from SADE), and use the mouse to select a
line of code. Then execute ‘Break’ from the SourceCmds menu.
Method number 1 is fine if your functions are small, otherwise counting the
individual lines of code could prove cumbersome.
Why does method number 2 work? When using version 6.1b7 and above of
Multi finder, MC68000 exceptions are passed to SADE, if present; if SADE isn’t a
con currently executing task, then a system exception occurs.
Personally, I think method number 3 is somewhat satirical; trying to guess
which machine instruction you are now (ahem, were) executing can cause brain
damage.
Method number 4, of course, appears to be the most user-friendly of them all.
So in practice, it would seem that all methods except number three can be easily
used to set break points in your own code. Refer to Figure 2 for an example of starting
up SADE and setting breakpoints. For an illustration of SADE stopping at a breakpoint,
please refer to Figure 3. The MPW C source listings will also provide more
information on how to set breakpoints within your own code.
One interesting thing I noticed is that a SysError() breakpoint will stop after
that line of code is executed, whereas setting a normal breakpoint will stop before that
line of code.
SADE has complete facilities for keeping track of variable values. You can either
perform a Show Value, which shows the contents of the variable of your choice, or you
can use the Watch feature. This feature is analogous to THINK’s Lightspeed Pascal’s
‘Observe’ window: every time a variable’s value changes, it is updated in a display
window for you. Please refer to Figure 4 for an example from the ‘Test’ program.
And of course, you have complete code stepping facilities: single step lines of
code, and even control whether or not you step into procedure calls.
Program Your Bugs Away
All of the aforementioned features can be found in most other debuggers.
However, the feature that sets SADE apart from any other debugger I’ve used is its
internal programming facility (henceforth, I’ll refer to SADE programs as ‘scripts’,
to differentiate these from your C & Pascal programs). You can actually write SADE
procedures and functions to automate debugging tasks. And if that’s not enough, how
about a slew of predefined procedures (even printf ) and reserved system variables?
Furthermore, complete expression evaluation is possible, including pointer
manipulation, bit-wise operations, and string manipulation.
The script facility of SADE is so extensive, it strongly resembles Pascal. Not
only that, SADE procedures and functions are fully capable of recursion. Unlike
Pascal, however, all variables are dynamically typed - based on their use in the
program; this would appear to be the result of an interpretative implementation of
this language.
To execute a SADE script, enter the script name (followed by any arguments) and