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-).