Path: utzoo!utgpu!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: <1122@atari.UUCP>
Date: 17 Aug 88 17:24:28 GMT
References: <8808090237.AA22529@ucbvax.berkeley.edu> <592@philmds.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 49

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

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. 

Unfortunately, this is not quite what you want: if you WANT to avoid
tracing through the trap handler, you pay a price.  Remember that the
SR which the TRAP instruction pushed has the trace bit set, but the
SR which the trace exception pushed has it clear.  If the
debugger doesn't set the T bit again, and rte's from the trace exception,
the trap handler will execute at full speed.  It will (presumably)
RTE, and restore the SR with the T bit set.  But since the T bit was
clear at the START of the RTE instruction, you get no trace exception
at the END of the RTE.  Since T bit is set at the START of the first
instruction after the TRAP (that is, the instruction the RTE returned to),
you will get the trace exception at the end of THAT instruction.  But
by now your PC points to the SECOND instruction after the TRAP.  This
is not ideal.

My debugger happens to have both modes: an "untrace" mode which
sets the T bit every time (and therefore single-steps through
trap handlers) and the normal mode, which treats trap instructions
specially: it sets a breakpoint immediately after the trap instruction,
and runs the trap instruction (and therefore the trap handler) at
full speed, without the T bit set at all.

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