Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.sys.atari.st Subject: Re: MW_C C-Source Debuger question Message-ID: <592@philmds.UUCP> Date: 16 Aug 88 11:24:39 GMT References: <8808090237.AA22529@ucbvax.berkeley.edu> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 61 In article <8808090237.AA22529@ucbvax.berkeley.edu> FORTINP%BNR.CA@FORSYTHE.STANFORD.EDU (Pierre Fortin, P.) writes: >Wellllll.... being a new-comer to the wonderful world of C (pronounced >"see" or "sea"? ;-}), I don't know how you C-soned (;-}) veterans ever >got along without it. However, in my first see-project (program to >find and display the BOMB information (registers and stacks)), I found >that CSD will not single-step within code which is executed while in >Super() mode. Am I doing something wrong, or is there a definite and >undocumented restriction to MW_C's CSD? Some remarks: When a debugger single-steps through your code, a commonly used technique is to push your program's current status word and program counter onto the supervisor stack, setting the trace bit in that status word and performing a RTE. When the instruction at your program's program counter gets executed, a trace exception occurs - and the debugger takes over control again because the trace vector has been set up to point into the debugger. The 68000 clears the trace bit in the status word whenever an exception occurs (otherwise your debugger would get single-stepped, but only the first instruction, recursively... 8-). This implies that you cannot single-step exceptions (this includes traps, and thus GEMDOS, BIOS, XBIOS and GEM traps), unless the debugger 'takes over' at an exception (needs a table for all old exception vectors, and all current exception vectors point into the debugger). This you probably have not noticed, because you step at source level (could well be done without trace bit, using breakpoints; this however is restricted to code in RAM). An (perhaps acceptable and maybe undocumented) restriction of CSD could thus be that it does not let you single-step a trap (whether this is in fact true I don't know); I've however seen this with other (code) debuggers for the ST. I checked the Super() call (got curious of course 8-), but as far as I can see, it correctly preserves the trace bit in the status word. That is, when the TRAP #1 exception finishes the bit is what it was before the exception occured; the code within the trap cannot be traced (unless ..., see above). Some hints: a) try what you did using the XBIOS Supexec call, which performs a function in supervisor mode. If this also does not work, I would suspect CSD having trouble with supervisor mode for some odd reason. b) Have you used Super() correctly? Example: long ssp; ssp = Super(0L); /* save supervisor stack pointer & switch to s. mode */ /* supervisory stuff here , with ssp == usp */ Super(ssp); /* back to user mode, restore old supervisor stack ptr. */ An error you could have made easily is calling Super without argument... Hope this helps - Leo. P.S. A simple program to display the bomb info I posted to this group some months ago (does not show stacks); you can have it, unless of course you want to 'C for yourself' 8-).