Exceptions in WinUAE debugger after RTS

[Cv365]

Hi! I'm just getting my feet wet with assembler and practising doing system calls. I have a very simple program that allocates some chip mem, frees is and exits.

If I run this on the commandline without setting breakpoints / using the debugger, it exits with no problem. However, if I add a watch/breakpoint on memory location $100, which is cleared at the beginning of my code (thanks for the great tip, Toni!) and I step through each instruction using the built-in WinUAE debugger, something goes horribly wrong after the last instruction (RTS).

After the RTS, the debugger spews out a seemingly neverending loop of Exceptions (number 26 and 27), which locks up the debugger window, due to the scrolling. I can only close the debugger window using its window close gadget. Not long after, the Amiga locks up and reboots.

I am sure I am missing something important here due to my noobishness. Is it something wrong with my code, or is it being caused somehow by using the debugger? Here's my code:

    INCLUDE "exec/types.i"
    INCLUDE "exec/memory.i"
    INCLUDE "exec/exec_lib.i"
    

CODE

    CLR.W	$100			            ; breakpoint for debug
    MOVEA.L	$00000004,A6		        ; load ExecBase
    MOVE.L	#32,D0			            ; how many bytes to alloc
    MOVE.L	#MEMF_CHIP|MEMF_CLEAR,D1    ; memory attribs
    JSR 	_LVOAllocMem(A6)	        ; allocate it
    MOVEA.L	D0,A1			            ; start of allocd mem
    MOVE.L	#32,D0			            ; size
    JSR	_LVOFreeMem(A6)		            ; free it
    CLR.L	D0			                ; return zero to system
    RTS				                    ; done
    
    END

P.S.: I know I'm not checking whether AllocMem succeeds in my code, but in the debugger I have confirmed that the call succeeds. I have also tried allocating Fast mem. Same deal.

[Cv365]

OK, managed to figure it out myself and posting here in case it helps someone else in the future.

It appears I was using the 'z' debugger command to step through all the instructions. Doing the 'z' command when the PC was at the RTS instruction was what causes the exceptions. If I simply use the 't' command to step through instructions, everything is just fine! D'oh. I stumbled upon this while stepping through another piece of code and I got all sorts of weird exceptions there as well.

I can manage now, but I am still slightly confused as to the workings of the 'z' command. Here's what the help says:

  t [instructions]      Step one or more instructions.
  z                     Step through one instruction - useful for JSR, DBRA etc.

So, obviously 't' steps through every instruction and also dives into subroutines, whereas 'z' will do the whole subroutine and then drop back into the debugger. Why then, does it cause exceptions on certain instructions? Should I *only* use 'z' with JSR, DBRA and the likes? I'd like to know what I am missing here

[meynaf]

First, what you're getting is interrupts (actually level 2 & 3), not exceptions.
Second, you can't step thru rts - i don't know winuae debugger but i guess it's the same as setting a breakpoint at next instruction, however there is nothing after this one...
So you return to the system and you're probably just getting system interrupts.

[Toni Wilen]

It reports all exceptions (interrups are also exceptions) during z.

Debugger is designed for debugging programs that take over the system and reported exceptions help if something strange happened in skipped subroutine.

z condition is simple: break to debugger when PC=next instruction.

[Cv365]

Ah, perfect. That actually cleared up a whole lot of things for me. Thx guys!