Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!husc6!ut-sally!brian
From: brian@ut-sally.UUCP (Brian H. Powell)
Newsgroups: net.micro.mac
Subject: _Debugger trap failure
Message-ID: <1084@rsch.wisc.edu>
Date: Fri, 25-Jul-86 00:55:51 EDT
Article-I.D.: rsch.1084
Posted: Fri Jul 25 00:55:51 1986
Date-Received: Fri, 25-Jul-86 07:13:14 EDT
Sender: news@rsch.wisc.edu
Organization: U. Texas CS Dept., Austin, Texas
Lines: 29
Keywords: MacDB, What Apple meant to say was...


     I was just reading the MacsBug version 5.1 documentation that came
in Supplement Volume I, Issue 3 (the March/June 1986 supplement).  I noticed
on one of the pages that they don't want anyone using Line-1111 traps anymore
to break into a debugger.  (They will interfere with the 68881.)  (And by the
way, this warning was in the December/February supplement also, but I didn't
notice it then.)
     Fine, I thought.  I am always ready to follow the Apple Guidelines.  I'll
just change this "dc.w $ff00" statement to the approved "_Debugger" trap.
Assemble; link.  Run.
     Boom.  A bomb box (with a debugger installed!)  ID=12.  The old dsCoreErr.
Unimplemented trap.  My debugger was virtually helpless.  Reboot.

     You see, Apple doesn't really have an $a9ff (_debugger) trap.  They fake
it in the debugger.  I think it only works with the new 5.* series MacsBugs.
I was using a Mac+ with MacNub A debugged by a 128K Mac running MacDB A.  I'm
using a (Darin Adler) NoQuiche system, version 3.2.
     Conclusion:
	The documentation is misleading.  Just thought you'd want to know.
     Since
	1)  I don't plan to have the debug trap in the final code, and
	2)  I don't have a 68881 yet,
this isn't really a problem.  I'd much rather use MacDB than MacsBug since
I have two macs, so I'll continue using the Line-1111 traps to debug.  I just
think Apple should have qualified the warning.

Brian H. Powell
		UUCP:	{ihnp4,seismo,ctvax}!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU