Hello,
One of the most common accidents I have while debugging with Hatari, is landing in interrupt code while single-stepping to inspect context for a bug.
For a start, breaking into the program/debugger using they keyboard shortcut (F10 in my case) seems to queue up at least one interrupt which occurs on the very first single-step operation. This can't be just bad luck because it happens nearly every time I do it. There's something strange about this behaviour - I'm just not sure what!
So to get around this I have a rather tedious procedure each time I break in - set a breakpoint ahead of the break and continue, to soak up the pending interrupt so I can start stepping. e.g.
> trace cpu_disasm
> b pc=$6537e
CPU condition breakpoint 1 with 1 condition(s) added:
pc = $6537e
> c
Returning to emulation....
cpu video_cyc= 100 100@ 0 : 0005FD6C 46fc 2700 MV2SR.W #$2700
cpu video_cyc= 110 110@ 0 : 0005FD70 4ef0 01f1 000b 7458 JMP.L (D0.W*1+750680)+0 == $0005fd78
cpu video_cyc= 118 118@ 0 : 0005FD78 2f00 MOVE.L D0,-(A7)
cpu video_cyc= 124 124@ 0 : 0005FD7A 1039 0017 02bc MOVE.B $001702bc,D0
cpu video_cyc= 128 128@ 0 : 0005FD80 6750 BEQ.B #$00000050 == $0005FDD2 (F)
cpu video_cyc= 130 130@ 0 : 0005FD82 08f8 0000 fa07 BSET.B #$0000,$fffffa07
cpu video_cyc= 142 142@ 0 : 0005FD88 4238 fa1b CLR.B $fffffa1b
cpu video_cyc= 148 148@ 0 : 0005FD8C 11c0 fa21 MOVE.B D0,$fffffa21
cpu video_cyc= 154 154@ 0 : 0005FD90 11fc 0008 fa1b MOVE.B #$08,$fffffa1b
cpu video_cyc= 162 162@ 0 : 0005FD96 23fc 0005 fdf6 000b 7458 MOVE.L #$0005fdf6,$000b7458
cpu video_cyc= 170 170@ 0 : 0005FDA0 21fc 0005 fdf8 0120 MOVE.L #$0005fdf8,$00000120
cpu video_cyc= 178 178@ 0 : 0005FDA8 4a39 002d 6da2 TST.B $002d6da2
cpu video_cyc= 182 182@ 0 : 0005FDAE 6722 BEQ.B #$00000022 == $0005FDD2 (F)
cpu video_cyc= 184 184@ 0 : 0005FDB0 31f9 000b 744a 82c2 MOVE.W $000b744a,$ffff82c2
cpu video_cyc= 192 192@ 0 : 0005FDB8 4a39 002d 6da3 TST.B $002d6da3
cpu video_cyc= 196 196@ 0 : 0005FDBE 6712 BEQ.B #$00000012 == $0005FDD2 (T)
cpu video_cyc= 200 200@ 0 : 0005FDD2 201f MOVE.L (A7)+,D0
cpu video_cyc= 206 206@ 0 : 0005FDD4 4a79 0017 02ac TST.W $001702ac
cpu video_cyc= 210 210@ 0 : 0005FDDA 6706 BEQ.B #$00000006 == $0005FDE2 (T)
cpu video_cyc= 214 214@ 0 : 0005FDE2 52b9 0017 0258 ADD.L #$00000001,$00170258
cpu video_cyc= 224 224@ 0 : 0005FDE8 5279 002d 3f8c ADD.W #$00000001,$002d3f8c
cpu video_cyc= 230 230@ 0 : 0005FDEE 52b8 0462 ADD.L #$00000001,$00000462
cpu video_cyc= 240 240@ 0 : 0005FDF2 52b8 0466 ADD.L #$00000001,$00000466
cpu video_cyc= 250 250@ 0 : 0005FDF6 4e73 RTE.L
cpu video_cyc= 264 264@ 0 : 0006537A 7608 MOVE.L #$00000008,D3
cpu video_cyc= 266 266@ 0 : 0006537C 7000 MOVE.L #$00000000,D0
1. CPU breakpoint condition(s) matched 1 times.
pc = $6537e
CPU=$6537e, VBL=13527, FrameCycles=268, HBL=0, LineCycles=268, DSP=$f33
>
I'm also not sure if there's a nice easy way to prevent this kind of thing generally - like a 'step' command that steps until the next instruction at the same processor exception level, rather than the next instruction literally. Again this is something that doesn't seem to occur in a normal debugger - probably because there are several types of stepping command (step next, step over.. etc) with more complicated logic behind them.
Typically the 'step over' in a debugger will execute subroutines and interrupts, but understands branches/loops. e.g. it stops not at the next sequential address but rather the next sequential instruction at the branch target - which prevents accidents like completing a loop vs stepping back to the loop start.
I'm probably missing something important here, so please enlighten me :-) Is it something that should be done by writing scripts? And can such scripts be generic enough to be used as stepping commands for any typical program, or is scripting mainly to accelerate one specific scenario when dealing with one known bit of code?
Any input welcome! Thanks,
Doug.