Path: utzoo!attcan!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: MW_C C-Source Debuger question
Message-ID: <1131@atari.UUCP>
Date: 24 Aug 88 18:34:29 GMT
References: <8808090237.AA22529@ucbvax.berkeley.edu> <592@philmds.UUCP> <1122@atari.UUCP> <610@philmds.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 72

In article <610@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
> --------------------- 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 --------------------------------
> 
> 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.

First, your experience with sid.prg is misleading because sid, like my
debugger, treats the trap instruction specifically so you DO see
reasonable behavior. 

Second, your quote starts with the correct sentence: when the trace bit
is set, a trace exception will occur immediately following the execution
of the target instruction.  This is exactly what I said. 

All the indented comments are in fact not correct.  The first two have
the same wrong interpretation.  When the T bit is set at the start of
the TRAP instruction, the exception will be taken at the end of the TRAP
instruction, when the PC is in the OS.  The SR stacked by the trap
instruction will have the T bit set, but the SR stacked by the trace
exception won't.  The debugger DOES get control, but has to set the T
bit explicitly if it wants to step through the trap handler.  If it just
RTEs from the trace exception, it will lose control (because, as I said,
the SR from the trace exception has the T bit clear). 

The third indented comment says that RTE causes the debugger to lose
control.  This is also untrue.  The T bit in the SR at the START of the
RTE instruction is the one which will cause the trace exception at the
END of the RTE instruction, even if the T bit in the SR which the RTE
got off the stack is clear. 

The last one suffers from the same misconception all over again.  In all
four cases, the author misunderstands the effect of the T bit.  He
thinks that if the T bit is cleared during the execution of an
instruction, you don't get the trace exception at the end of that
instruction.  This is just not true. 

I quote: "If the T bit is asserted (on) at the beginning of the
execution of and instruction, a trace exception will be generated after
the execution of that instruction has completed." M68000 8-/16-/32-Bit
Microprocessors Programmer's Reference Manual, Fifth Edition, by
Motorola, copyrights 1979 through 1986, page 4-12. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt