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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 13/04/2024 à 14:06, Eero Tamminen a écrit :

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

Hi

the stacked PC when an exception occurs is indeed pointing to the next 
instruction most of the time.

See "6.2.5 Exception Processing Sequence"
"[...]The current program counter value and the saved copy of the status 
register are stacked using the SSP. The stacked program counter value 
usually points to the next unexecuted instruction.
However, for bus error and address error, the value stacked for the 
program counter is unpredictable and may be incremented from the address 
of the instruction that caused the error"

So, it's complicated to point to the instruction causing the exception 
when using the stacked PC.

To get the PC value, we use M68K_GETPC (which is a define for 
m68k_getpc()), we would need sthg like get_previous_pc(), but as far as 
I see the cpu core doesn't maintain such value (it would add some 
overhead to do this on all instruction)

Maybe the debugger could always keep a minimal history of at least the 2 
latest instruction, which would help to know the PC of the faulty 
instruction, but that would mean some overhead too

Nicolas