[hatari-devel] DSP debugger

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


I think the DSP debugger is somehow broken - several times recently I have tried to trace code and found the debugger switching to 68k disasm mode, and then forgetting where the DSP PC was, unable to continue execution.

This seems to happen if the DSP disassembler is asked to disassemble an invalid instruction. e.g. 

dd $xxxx

where xxxx = 2nd (data) word of a 2-word instruction

Here is a sample where the program is broken into at a sensible place:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$153
$035c36 : 67fa                                 beq.s     $35c32
> dd pc
DSP disasm 0x153-0x15b:
p:0153  0e2151         (04 cyc)  jne p:$0151
p:0154  47f000 004004  (04 cyc)  move x:$4004,y1
p:0156  56f000 004003  (04 cyc)  move x:$4003,a
p:0158  66f000 004002  (04 cyc)  move x:$4002,r6
p:015a  00000c         (04 cyc)  rts


...and then gather info on the stack...

> info dsp
DSP core information:
- SSH stack: 0000 0000 01fd 020f 0135 00de 03bd 0000 0000 0000 0000 0000 0000 0000 0000 0000
- SSL stack: 0000 0000 0055 8054 8054 8054 8050 0000 0000 0000 0000 0000 0000 0000 0000 0000
- Interrupt IPL: 0003 0003 0003 0003 0003 0002 0002 0002 ffff ffff ffff ffff
- Pending ints:  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
- Hostport: 00 12 02 0f 00 ff ff ff 00 00 00 06


And then diassemble one of the stack locations...

> dd $3bd
DSP disasm 0x3bd-0x3c5:
p:03bd  56e100         (04 cyc)  move x:(r1),a
p:03be  0604a0         (04 cyc)  rep #$04
p:03bf  200032         (02 cyc)  asl a
p:03c0  565900         (04 cyc)  move a,x:(r1)+
p:03c1  4cae00         (02 cyc)  move y:$002e,x0
p:03c2  46ec00         (04 cyc)  move x:(r4+n4),y0
p:03c3  47ed00         (04 cyc)  move x:(r5+n5),y1
p:03c4  20001b         (02 cyc)  clr b


And then things start to go wrong when we disassemble a bad location, one word back....

> dd $3bc
DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc
$035c36 : 67fa                                 beq.s     $35c32


...showing a 68k disassembly instead of DSP!


But one additional word back from here and the location disassembles correctly again, being a valid instruction:

> dd $3bb
DSP disasm 0x3bb-0x3c3:
p:03bb  060280 0003c0  (06 cyc)  do #$0002,p:$03c0
p:03bd  56e100         (04 cyc)  move x:(r1),a
p:03be  0604a0         (04 cyc)  rep #$04
p:03bf  200032         (02 cyc)  asl a
p:03c0  565900         (04 cyc)  move a,x:(r1)+
p:03c1  4cae00         (02 cyc)  move y:$002e,x0
p:03c2  46ec00         (04 cyc)  move x:(r4+n4),y0


Disassemble a few more locations from the stack.....

> dd $1fd
DSP disasm 0x1fd-0x205:
p:01fd  44f400 000100  (04 cyc)  move #$000100,x0
p:01ff  5ef000 0005f1  (06 cyc)  move y:$05f1,a
p:0201  4cf040 0005f2  (06 cyc)  add x0,a y:$05f2,x0
p:0203  200045         (02 cyc)  cmp x0,a
p:0204  0af0ab 00020b  (06 cyc)  jmi p:$020b

> dd $1fb
DSP disasm 0x1fb-0x203:
p:01fb  069f80 000216  (06 cyc)  do #$009f,p:$0216
p:01fd  44f400 000100  (04 cyc)  move #$000100,x0
p:01ff  5ef000 0005f1  (06 cyc)  move y:$05f1,a
p:0201  4cf040 0005f2  (06 cyc)  add x0,a y:$05f2,x0


...but having done nothing at all with the machine state, Hatari no longer diassembles the interrupted PC address!

> dd pc
DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc
$035c36 : 67fa                                 beq.s     $35c32

> dd pc
DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc
$035c36 : 67fa                                 beq.s     $35c32

...instead it's trying to disassemble $3bc - the bad opcode encountered a few steps back, and reporting 68k info.

...so we try to trace the original code interrupted....

> ds
p:03bc  0003c0         (00 cyc)  dc $0003c0
p:03bd  56e100         (04 cyc)  move x:(r1),a
p:03be  0604a0         (04 cyc)  rep #$04
p:03bf  200032         (02 cyc)  asl a
p:03c0  565900         (04 cyc)  move a,x:(r1)+
p:03c1  4cae00         (02 cyc)  move y:$002e,x0
p:03c2  46ec00         (04 cyc)  move x:(r4+n4),y0
p:03c3  47ed00         (04 cyc)  move x:(r5+n5),y1


...and it now executes from $3bc instead of the interrupted PC address!

> dd $3bb
DSP disasm 0x3bb-0x3c3:
p:03bb  060280 0003c0  (06 cyc)  do #$0002,p:$03c0
p:03bd  56e100         (04 cyc)  move x:(r1),a
p:03be  0604a0         (04 cyc)  rep #$04
p:03bf  200032         (02 cyc)  asl a
p:03c0  565900         (04 cyc)  move a,x:(r1)+
p:03c1  4cae00         (02 cyc)  move y:$002e,x0
p:03c2  46ec00         (04 cyc)  move x:(r4+n4),y0

The pattern seems to be where you diassemble a bad opcode, then disassemble a good one - the PC seems to magically jump to the bad address without executing anything. Other things may also be happening but this at least is reproducible.

I'm not sure when this problem began - perhaps late in version 1.7. I'm sure it was not present in v1.6 because I used the debugger a lot then and never noticed it. I seem to run into this regularly now - during most debug sessions using v1.8. 

D





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/