Re: [hatari-devel] Small patch to support debugging Line-F exceptions

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 13.4.2024 8.43, Thorsten Otto wrote:
> 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.

Thanks, I verified that it does not interfere with line-A / line-F 
breakpoints:
---------------------------------------------------
$ head line-a.ini disasm-pc.ini
==> linea.ini <==
b lineAopcode ! lineAopcode && lineAopcode ! 0xffff :file disasm-pc.ini 
:trace :quiet

==> disasm-pc.ini <==
d pc-"pc+1"
---------------------------------------------------

When one enables both breakpoint and exception catching:
---------------------------------------------------
hatari --parse linea.ini -D --debug-except linea -m fishes.prg
---------------------------------------------------


> 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.

I dropped that part before pushing, as it should have its own flag / 
name, and because there are a lot of other non-ST exceptions that could 
be added at the same time, at which point it does not any more make 
sense to use array indexes in DebugUI_Exceptions(), but add the 
exception number as struct member & scan the array for match.

As to CLI option names, maybe "unimpl_addr" and "unimpl_instr"?

Exceptions 12-15 could be e.g "emulator" (Emulator interrupt), "copro" 
(Coprocessor protocol violation), "format" (Format error), 
"uninitialized" (Uninitialized interrupt), exception 24 "spurious" 
(Spurious interrupt), exception 56 "mmu" (MMU configuration error), and 
48-54 exceptions "fpu_unordered" (Unordered condition for FPCP branch or 
set), "fpu_inexact", "fpu_divzero", "fpu_underflow", "fpu_nan" 
(signaling NAN).

Autovectors may be best handled by debugger variable and breakpoints.


> > 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.

Btw. If you enable CPU history tracking, when "disasm" command is called 
after invoking debugger, it shows executed instructions around PC, 
instead of just from PC.


> This does not happen e.g. for pmove (with MMU emulation disabled):
....
> IMHO the debugger should always print the instruction causing the exception,
> even if the PC has already advanced.

PC value comes from the WinUAE core, and I think in some rare cases(?) 
PC can actually be on a different instruction, but I do not know whether 
this would be one of those, or is Hatari code calling debugger too late 
from the CPU core.  Nicolas?


	- Eero