gtusar@nmsu.edu (Gregory A. Tusar) (03/23/89)
I'm sorry if this has been brought up before, but I haven't seen it discussed, so 1) Is there any way to catch bus error exceptions? 2) If this can be done, is there any way to look at the stack frame that gets generated by the exception, or, better yet, has anyone written some hook that will dump a core image? It makes it real hard to debug stuff, without anything like this... thanks, greg -- ---------------------------------------------------------------- greg tusar gtusar@NMSU.edu USnail 3000 Majestic Ridge #89, Las Cruces NM 88001
daveh@cbmvax.UUCP (Dave Haynie) (03/24/89)
in article <GTUSAR.89Mar22164412@san_juan.nmsu.edu>, gtusar@nmsu.edu (Gregory A. Tusar) says: > I'm sorry if this has been brought up before, but I haven't seen it discussed, so > 1) Is there any way to catch bus error exceptions? Of course, and far as I know, you have your choice. You can set the exception vector of your particular task, supplying a program of your own as the handler. The stack frame is mentioned in the Rom Kernel Manual; it's basically the normal 680x0 stack frame, plus at the top the exception number that caused the exception. I use a bit of this, to examine Privilege vs. F-Line exceptions in the GetMMUType() routine in my SetCPU V1.4 program. The other thing you should be able to do is directly "poke" the 680x0 exception vector for a Bus Error (level 2) exception. This may not be fully compatible with future OS versions (some may use the vector base register to move this stuff out of CHIP RAM), but it should work for now; I suspect that the GOMF program does this. The question that should be asked, though, is why you want to trap Bus Errors. Except for the event of a PIC collision on the expansion bus, the current systems won't generate a bus error on their own. Obviously a dedicated card or an MMU might. > 2) If this can be done, is there any way to look at the stack frame > that gets generated by the exception, or, better yet, has anyone > written some hook that will dump a core image? Well, you'd need the proper handler program -- apparently the latest GOMF is of this class. Also, the Manx symbolic debugger DB and the one of the latest Lattice startup modules attempt to trap exceptions. Looking for Bus Error alone is not going to get you very far -- most of the likely exceptions are purely software exceptions, which are handled with some success (depending on who actually died -- a bad pointer generated by your program could actually cause a library call to crash, which could very well hang the system) by the aforementioned tools. Haven't seen anything that would actually dump a core image; that might allow some reasonable port mortem analysis if the required filesystem doesn't get clobbered by the program crash. At Commodore, we have some hardware devices that allow such a port mortem examination to be done on a suitably equipped target machine, but far as I know there's nothing commercially available to do this, and, being hardware, it wouldn't likely be cheap. > It makes it real hard to debug stuff, without anything like this... What exactly are you trying to debug? Using basic debuggers and source level debuggers, I have yet to find a single problem that takes more than a night or so to solve. Our OS guys sometimes use analyzers or emulators, which can certainly be used by anyone to speed debugging, but add a nontrivial extra cost to the prospect. What is it that you see failing that can't be solved with the current software tools that are available? > thanks, > greg -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession