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
Summary: It's like Allan said it was
Keywords: trace bit, trap, exception handler
Message-ID: <620@philmds.UUCP>
Date: 24 Aug 88 17:32:02 GMT
References: <8808090237.AA22529@ucbvax.berkeley.edu> <592@philmds.UUCP> <1122@atari.UUCP> <610@philmds.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 52

In article <610@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|In article <1122@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
   [some stuff deleted]...
||When the trace bit is on at the START of an instruction, the trace
||exception will happen at the END of the instruction.  What this means is
||that if the T bit is on at the start of the TRAP instruction, the
||debugger will get the trace exception at the END of the TRAP instruction
||-- when the PC is at the first instruction of the trap handler.  The SR
||at this point is clear (because the TRAP instruction cleared it), but
||the debugger is free to set it again. 
|   [rest deleted]...
|
|To show that I'm not making things up, I quote from 'Programming the 68000'
|by Steve Williams (edition by Sybex), page 357, Exception Processing
|(hope I'm not sued for copyrights, but then, this is for educational purposes
|only 8-):

   [quotation deleted]...

|I should say this contradicts what Allan said. I'm not saying who's right
|or wrong, but I'm getting curious at the *REAL* facts.

Being curious and all, I checked things by writing a primitive
debugger; the *REAL* facts are that Allan was indeed right.
The book though seems misleading at this point, if not to say
incorrect:

      o Since an exception clears the trace bit, an exception caused by
        the instruction being traced causes the debugger to lose control,
        unless the debugger receives control when exceptions occur.

The debugger can always *TAKE* control, just by setting the trace bit
after the exception occured. The above statement seems to imply that

exception happens --> debugger receives control
                      OR
                  --> debugger loses control

which simply isn't true. Just like Allan said, the debugger receives
control after the exception occured (the trace bit in the status word
on the stack being cleared by the exception). When the debugger resumes
the user program (by performing an RTE) it may be with or without this
trace bit set again.  In the first case the exception handler will be
single-stepped, in the second case the debugger regains control when
the exception handler RTE's, because the status word with trace bit set
was pushed onto the supervisor stack when the exception occured.

Which makes me wonder why Allan used a break point to 'go at full speed'
through the exception handler; this neither seems necessary in this case,
seeing the above, nor wanted (you cannot 'break point' ROM code).

                           Leo.