brian@ut-sally.UUCP (Brian H. Powell) (07/25/86)
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.EDUdlc@lanl.ARPA (Dale Carstensen) (07/27/86)
> 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. 1. Unrelated, but this message was in the news here 5 times, including 3 in a row! 2. In fairness to Apple, who I am certainly willing to criticize when they blow it, you must admit the documentation that said to use $a9ff and not a 1111 trap was not for MacDB and MacNub, it was for the current version of MacsBug. Only.
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (07/28/86)
> 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.... > 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've been using _Debugger for about 1.5 years, since I started using MDS version 0.5. I have never had the problem described here. The Mac always obediently drops into Macsbug (even pre-historic versions) with an indication "USERBRK" in that cute, brain-damaged font it uses.
wert@iapetus.rice.edu@rice.EDU (Scott Comer) (07/29/86)
In article <5401@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > > 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. Well, this message was somewhat misleading as well. 1) There is a A9FF trap. It invokes the DS Alert (ID=12) which is what happened to you. 2) Since the documentation was for Macsbug and NOT MacNub, it might not apply. Or there might be bugs. I remember that MacNub and MacDB have never tracked Macsbug very closely. I have been using the A9FF trap for over a year, with whatever the current version of Macsbug has been at the time (4.* and now 5.1*. It has always worked. 3) Macsbug installs its own trap handler (in place of the system A line trap dispatch routine) and catches the A9FF trap inline, without using the trap dispatch table. Your debugger may do this differently, or not at all. If you are just doing debugging, there really is nothing wrong with using F line traps to do it. One advantage to using the A line debugger trap is that you can turn it off from within the debugger. Also, eventually you will have to find another debugging method, so you might as well start right now. Apple is just covering their *ss. scott