🚀 go-pugleaf

In article <620@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
> [The debugger gets the trace exception at the end of the trap instruction,
> with the stacked PC at the first instruction of the trap handler and
> the stacked SR has the trace bit clear.]
>
> 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.

Once again you are imposing what you think should happen on reality, and
it doesn't fit.  Remember that the trace exception happens when the
trace bit was ON at the START of the instruction.  But in the RTE from
the trap, the trace bit is getting set DURING the RTE instruction, so no
trace exception happens after the RTE instruction.  The trace bit is now
set at the START of the instruction that the RTE returns to, so the
trace exception happens AFTER THAT INSTRUCTION.  The result: you don't
see that instruction before it executes.  But that's not what you expect
from a debugger (and not what you get from sid): you expect to see every
instruction before it executes.  So you use a breakpoint to emulate the
behavior you expect.  The breakpoint it set on the instruction after
the TRAP, so you see that instruction before it executes.

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