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