| Re: [hatari-devel] Small patch to support debugging Line-F exceptions |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
This is a multi-part message in MIME format.
On Samstag, 13. April 2024 00:39:46 CEST Eero Tamminen wrote:
> Could you send updated "git format-patch" version of the patch?
Sure, attached below. I've also included '060 unimplemented effective address
exception to be handled as Line-F in this check. Eventually '060 unimplemented
instruction should be treated similar, but i wasn't sure which flag should
trigger that.
> Is this with the UAE core, or (deprecated) external disassembler?
With the UAE core.
There is another thing: when entering the debugger, it printed the address of
the next instruction, not the one that caused the exception. This does not
happen e.g. for pmove (with MMU emulation disabled):
Line-F exception at 0xe000ca!
----------------------------------------------------------------------
You have entered debug mode. Type c to continue emulation, h for help.
CPU=$e000ca, VBL=0, FrameCycles=68, HBL=0, LineCycles=68, DSP=$0
00E000CA F010 0800 [ pmove (a0),tt0 ]
(from check in EmuTOS whether MMU is present)
CPU=$102f3dc, VBL=656, FrameCycles=470781, HBL=231, LineCycles=1389, DSP=$51
0102F3DC F23C 5623 4058 0000 0000 0000 fmul.d ##9.600000e+01,fp4
(from the program that crashed because using fsin).
The actual instruction was just before:
0102F3D8 F200 120E fsin.x fp4
(PC)
0102F3DC F23C 5623 4058 0000 0000 0000 fmul.d ##9.600000e+01,fp4
IMHO the debugger should always print the instruction causing the exception,
even if the PC has already advanced.