🚀 go-pugleaf

I posted a query last week asking if there was a debugger for Apple Pascal.
By and large the responses were negative (some maybes, no affirmatives).

I think it's evident to anyone who has used Apple's Pascal that the error
messages are generally not very useful.  I won't bother with the indictment.
Let me propose a debugging technique that is crude but effective, 
and expandable.

Given a procedure "X" that is compiled and linked into the buggy program, 
but never actually called by the program.  When the OS traps an error,
instead of (or in addition to) the usual "Urrp!  Press any key to reset",
the OS would invoke the procedure X.  Presumably X has not been trashed out
by the error (no guarantees on that one), and X has enough knowledge of
the memory map and stack frames to perform some reasonable debugging.

X can take on many forms.  One that might be useful would be the proverbial
"core dump" routine.  To wit: X dumps the Apple's memory to a disk file 
for later analysis.  This has several advantages: X is small; the machine
will be in a sane (reset) state during the analysis; several kinds of
analyzers could be used independently or together on the same core file.

The analyzers could be interactive (ala sdb), or a simple stack back trace
with local variables displayed (always in good taste).  This is the
expandable part: not only can the person-one-smarter-than-you write a
useful analyzer for Apple Pascal users, but the core file could be
"standardized" such that it could be transportable to others.
Just think: a whole new industry of core-fixers.  Just send them your core
dump and a check, and poof! back comes your bug, all solved.

Now for my next query.  This is targeted primarily at Apple Corp. & UCSD.
How can I get the OS to invoke my function "X" when it has trapped a fatal
error?  How can I get more details on the memory layout, stack frame and
global areas in Apple Pascal?

Ever Forward,
tim born