| Re: [hatari-devel] MEMWATCH freezes Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 13/10/2018 à 11:02, Nicolas Pomarède a écrit :
Myabe it would be better to track the issue with pure debugger, it's
likely that the code is easier to follow, especially if there's a double
bus error, this is often very close to the cause of the exception.
hi
I was able to test this issue with pure debugger and I think the
rte/rerun is not fixed yet, the PC is not set to the faulty instruction
but to the next instruction.
I tested with prefetch=off and CE=off as well as with CE=on
In both cases, it doesn't rerun.
The simpler case might be with prefetch=off and CE=off :
This is the "faulty" instruction (memory is write protected, so it
triggers a bus error) :
0001E270 43f0 1001 LEA.L (A0, D1.W*1, $01) == $0001e0eb,A1
0001E274 4211 CLR.B (A1)
This calls 1a822, which is just an intermediate handler and calls 1a832
which is the real bus error handler
0001A822 2f2f 0004 MOVE.L (A7, $0004) == $00005700
[e274b008],-(A7) [00040000]
0001A826 0297 0000 0fff AND.L #$00000fff,(A7) [e274b008]
0001A82C 2eb7 0151 MOVE.L (A7, D0.W*1+0)+0 == $00000008
[0001a832],(A7) [00000008]
0001A830 4e75 RTS
0001A832 48e7 8002 MOVEM.L D0/A6,-(A7)
Here, A7=$56fc and the stack is :
000056FC: 03 00 00 01 e2 74 b0 08 00 00 03 11 00 00 00 00
0000570C: 00 01 e0 eb 00 00 42 11 00 00 00 00 00 01 e0 eb
0000571C: 00 00 00 00 00 01 e0 eb 00 00 3f 00 00 01 e0 eb
0000572C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000573C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So, return PC is correctly set to 1e274, the faulty instruction.
0001A836 4def 0008 LEA.L (A7, $0008) == $000056fc,A6
0001A83A 0c6e 1008 0006 CMP.W #$1008,(A6, $0006) == $00005702
[b008]
0001A840 6604 BNE.B #$04 == $0001a846 (T)
0001A846 102e 000b MOVE.B (A6, $000b) == $00005707 [11],D0
0001A84A 4e7b 0001 MOVEC D0,DFC
0001A84E f036 9c01 0161 MMUOP030 (A6, A1.L*4, $01) ==
$0007daa9,#$0161
0001A856 558f SUBA.L #$02,A7
0001A858 f017 6200 MMUOP030 (A7),#$6200
0001A85C 081f 0003 BTST.B #$0003,(A7)+ [0a]
0001A860 660e BNE.B #$0e == $0001a870 (T)
0001A870 202e 0010 MOVE.L (A6, $0010) == $0000570c
[0001e0eb],D0
0001A874 2c70 01e2 04f2 0028 MOVEA.L (D0.W*1+1266)+40 == $00e00028
[0000771e],A6
0001A87C 2c56 MOVEA.L (A6) [0001e06a],A6
0001A87E 90ae 0008 SUB.L (A6, $0008) == $0001e072
[0001e16a],D0
0001A882 651e BCS.B #$1e == $0001a8a2 (T)
0001A8A2 4cdf 4001 MOVEM.L (A7)+,,D0/A6
0001A8A6 08ef 0002 000b BSET.B #$0002,(A7, $000b) == $00005707
[11]
FC bits are changed in SSW. At this point, A7=$56fc and the stack is :
000056FC: 03 00 00 01 e2 74 b0 08 00 00 03 15 00 00 00 00
0000570C: 00 01 e0 eb 00 00 42 11 00 00 00 00 00 01 e0 eb
0000571C: 00 00 00 00 00 01 e0 eb 00 00 3f 00 00 01 e0 eb
0000572C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000573C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So, it should still return to 1e274.
0001A8AC 4e73 RTE
0001E276 42a7 CLR.L -(A7)
0001E278 6036 BT .B #$36 == $0001e2b0 (T)
As can be seen, the RTE executes the instruction at 1e276, but the
"clr.b (a1)" at 1e274 is not retried.
So, in that case there's no instant crash, this clr.b might be useless
now, but the rerun behaviour was not correct.
I don't see anything obvious in m68k_do_rte_mmu030(), neither in code
for op_4e73.
Toni, do you see sthg with these traces or do you need more infos ?
Note that in m68k_do_rte_mmu030 there might be a bug with these lines :
uae_u32 ps = get_long_mmu030c(a7 + 0x28);
uae_u32 oc = get_long_mmu030c (a7 + 0x14);
shouldn't it be the non-cache version ?
uae_u32 ps = get_long_mmu030(a7 + 0x28);
uae_u32 oc = get_long_mmu030 (a7 + 0x14);
(but it doesn't change this case anyway)
Nicolas