Re: [hatari-devel] Bug in debugger when reading longs

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 23/01/2018 à 13:23, Miro Kropáček a écrit :
> Hi,
>
> I've found a bug, hopefully reproducible.
>
> > b a5 = $c4b4 && d2 = $11
> CPU condition breakpoint 2 with 2 condition(s) added:
>         a5 = $c4b4 && d2 = $11
> > c
> Returning to emulation...
> 2. CPU breakpoint condition(s) matched 1 times.
>         a5 = $c4b4 && d2 = $11
>
> CPU=$2344e8, VBL=902, FrameCycles=312027, HBL=152, LineCycles=731, DSP=$51
> $002344e8 : 5a8e                               addq.l    #5,a6
> > d pc
> $002344e8 : 5a8e                               addq.l    #5,a6
>
> (not important)
>
> Now the fun begins:
>
> > d "pc-$60"
> - 'pc-$60' -> $234488
> $00234488 : 4eb9 0005 32a4                     jsr       $532a4
> $0023448e : 508f                               addq.l    #8,sp
> $00234490 : 544d                               addq.w    #2,a5
> $00234492 : 568e                               addq.l    #3,a6
> $00234494 : bdf9 001d 58c8                     cmpa.l    $1d58c8,a6
> $0023449a : 6d00 0004                          blt       $2344a0
> $0023449e : 4e75                               rts
> *$002344a0 : 203c 0000 0005                     move.l    #5,d0 *
> $002344a6 : 3032 0800                          move.w    (a2,d0.l),d0
>
> OK, so I want to jump to the bold address...
>
> > r pc=$002344a0
> > d pc
> $002344a0 : 203c 0000 0005                     move.l    #5,d0
> $002344a6 : 3032 0800                          move.w    (a2,d0.l),d0
> $002344aa : e058                               ror.w     #8,d0
> $002344ac : d044                               add.w     d4,d0
>
> Looks good...
>
> > r
>   D0 0000C011   D1 00000000   D2 00000011   D3 00000000
>   D4 00000000   D5 00200011   D6 00087A00   D7 FFFFFFFF
>   A0 002344A0   A1 00233F1C   A2 001EC408   A3 001D6408
>   A4 000AA2CC   A5 0000C4B4   A6 0000006C   A7 0023136C
> USP  0023136C ISP  00008870 SFC  00000000 DFC  00000000
> CACR 00003111 VBR  00000000 CAAR 00000000 MSP  00000000
> T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
> 0: 3FFF-D3333333-33333800 #1.650000e+00 3FFC-FAE147AE-147B0000 
> #2.450000e-01
> 2: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
> 4: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
> 6: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
> FPSR: 08000000 FPCR: 00000000 FPIAR: 0003ea0e N=1 Z=0 I=0 NAN=0
> Prefetch 002344ec 001d58c8 (1) bdf9 (1) 001d (1) 58c8 (1)
> 002344A0 203c 0000 0005           MOVE.L #$00000005,D0
> Next PC: 002344a6
>
> Yup, still there...
>
> > n
>
> CPU=$2344a2, VBL=902, FrameCycles=312027, HBL=152, LineCycles=731, DSP=$51
> $002344a2 : 0000 0005
>
> Huh? Why are you doing this to me? :-) I can't find a workaround how to 
> trace this line at all. I guess it has something to do with not fetching 
> the operand.


Hi

Yes, the problem is that currently there's no "refetch" when PC reg is 
changed, so although you changed PC, the previously prefetched values 
were kept and the next instruction will be a mix between old prefetch 
values and new prefetch ones.

I already planned to have a look at this some time ago, I will try to 
give it a go.

Nicolas