jrd@STONY-BROOK.SCRC.Symbolics.COM (John R. Dunning) (01/27/88)
Can anyone tell me if there's a good way to trap the kinds of errors that usually result in bombs? I'm contemplating porting a debugger to the ST, but a fundamental piece of functionality is the ability to use my own trap vectors, or at least the get TOS to give control back to me with a pointer to the crash data. I would expect there to be some sort of OS call for this, but haven't seen it. Related question: Does MUSHROOM.PRG work? Whenever I run it it appears to just dump a piece of the system stack, with no indication of the user PC or failing instruction etc. It then crashes itself with an alignment error. Is there a better substitute for MUSHROOM, or documentation on where to find the crash data and how to interpret it? Thanks.
F1FPAW@DHHDESY3.BITNET (Jerzy Michal Pawlak) (02/01/88)
>Can anyone tell me if there's a good way to trap the kinds of errors >that usually result in bombs? The bombing routine is entered via the exception vectors (some of them are: bus error, address error, illegal instruction ...). Just change the vectors to point to your debugger. >Is there a better substitute for MUSHROOM, or >documentation on where to find the crash data and how to interpret it? Yes, I use MONST (very good!). By the way: MONST does trap bombs in a correct way. Michal Pawlak (I'm not an expert!)
apratt@atari.UUCP (Allan Pratt) (02/03/88)
in article <19880126193720.1.JRD@GRACKLE.SCRC.Symbolics.COM>, jrd@STONY-BROOK.SCRC.Symbolics.COM (John R. Dunning) says: > [...] or at least the get TOS to give control back to me > with a pointer to the crash data. I would expect there to be some sort > of OS call for this, but haven't seen it. > > Related question: Does MUSHROOM.PRG work? > Is there a better substitute for MUSHROOM, or > documentation on where to find the crash data and how to interpret it? If you mean the MUSHROOM.PRG from Silas Warner (a PLATO programmer from way back, and author of Castle Lichtenstein (?) on the Apple ][), it does work as far as it goes, but then it causes bombs and overwrites all that stack information. There is no TOS call to get control in bomb-like situations. Since you ask for one, it is possible that you don't have enough understanding of 68000 exceptions to port the debugger. I wrote an ultra-cool debugger for the ST, and it handles all the bomb-type errors. You have to take over the exceptions (bus error, address error, illegal instruction, etc.) yourself. The Hitchhiker's Guide to the BIOS has the definitive description of the bomb-save area. It contains the values of all the registers, including PC, USP, and SSP, and the top few words of the supervisor stack at the time of the bomb. The format can be found in the Guide, and possibly in such places as Abacus books (but I *never* trust an Abacus book to get it right.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt