Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!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: <610@philmds.UUCP>
Date: 22 Aug 88 21:47:31 GMT
References: <8808090237.AA22529@ucbvax.berkeley.edu> <592@philmds.UUCP> <1122@atari.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 73

In article <1122@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>In article <592@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>> Some remarks:
  [some remarks deleted 8-]...
>> 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), ...
>
>Having written a debugger, I can tell you that this is not the case.
>
>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-):

--------------------- start of quotation --------------------------------

  Single-stepping an instruction involves setting the Trace bit in the status
register. The most common method is to stack the Program Counter and
status register, set the Trace bit in the stacked status register, and execute
an RTE instruction. A trace exception will occur immediately following the
execution of the target instruction. Some side effects of this technique are:

      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.

      o TRAP instructions that call an operating-system function appear
        as a single instruction.

      o Tracing an RTE instruction causes the debugger to lose control
        because the RTE instruction reloads the status register. Tracing an
        instruction which reloads SR has the same effect. These instructions
        include MOVE to SR, ANDI to SR, and EORI to SR.

      o Tracing a MOVE from SR can cause the program to malfunction because
        the trace bit will be set in the copy of the status register that
        the program receives. If the program compares this copy without
        masking the trace bit, it could execute incorrectly.

--------------------- end of quotation --------------------------------

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.
Note also that I never said single-stepping trap handlers couldn't be
done; however, after reading this quote it seems not trivial. If you
don't take precautions (i.e. let the TRAP be vectored into the
debugger) the trap handler code is executed untraced; the status word
with the Trace bit set is reloaded from the stack when the RTE takes
place, causing a Trace exception at that point (the program counter
will point after the TRAP instruction).  At least this is what I make
of it!

My own experience with a code debugger for the ST (sid.prg) is that it
indeed performs a TRAP as if it were a single instruction (i.e. not single-
stepping the code within the trap handler); why this was just so isn't
clear now.

Any 68K experts care to comment on this one; I'm especially interested in
Allan's reply.

                        Leo.