[hatari-devel] Re: Hatari debugging help with WinUAE CPU core

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I'm CCing hatari-devel as here's WinUAE CPU and MMU specific stuff
of which I don't know that much.

On perjantai 10 tammikuu 2014, Douglas Little wrote:
> Some questions you might help me with re: Hatari
> 
> I have been watching a bug in the game which sometimes surfaces while
> profiling or running it in Hatari. (I think only when printfs are still
> enabled, but I'm not yet sure).
> 
> The errors reported by Hatari are an endless, non-interruptible stream of
> these:
> 
> Illegal ROMmem wput at ffe005e8
> Illegal ROMmem wput at ffe005ea
> Illegal ROMmem wput at ffe005ec
> ....
> 
> I'm not sure if this is an emulator- or emulation-level error,

It's emulator level error about something trying to write word sized
data over ROM address range.

> and something I should catch as a bus error, or by some other means.

Normally [1], it should generate bus error right after above message.


> I also see these:
> 
> Exception 2 (0) at 30 -> 0!
>
> And I'm not sure what they are - is that basically a bus error by a
> different name?

WinUAE CPU core messages look a bit different from oldUAE CPU core ones.

> Normally bus errors print an obvious message 'Bus error'

It seems that Hatari skips these messages if its TOS itself causing
the bus error. 

I'm not sure that's right.  TOS does some HW checks at startup which
cause bus errors, but apps calling TOS later on may cause TOS to bus
error later on by giving invalid inputs to OS calls, so knowing about
them would also be useful.


> and hit vector $8. I'm not sure how to interpret the above messages
> from Hatari.

[1] In WinUAE CPU core case, when MMU is enabled, there's special
    handling which uses Hatari's C-based set/longjmp emulation for
    WinUAE CPU core's C++ exception handling.

That code is pretty hard to follow, so I'm not sure whether you should
get normal bus error, or just some MMU specific exception.

With MMU, SSW register may be involved and emulation of that in Hatari
isn't currently complete.


> I'm generally finding it hard to trap these kind of errors when they only
> surface rarely and cause the Hatari console stream to choke with streams
> of confusing errors

There's a check in M68000_BusError() for SPCFLAG_BUSERROR, so
that Hatari doesn't generate multiple bus errors for the same address,
but I guess that with MMU, SPCFLAG_BUSERROR isn't used.

MMU exception handling in general might not be correct.


> - setting a breakpoint at ($8) doesn't seem to work
> reliably with these. Sometimes a lot of code is executed (and thousands
> of errors printed) before a bus error actually occurs and the CPU
> history is usually too short to be useful.
> 
> At a minimum, setting a cap on the number of error exceptions printed
> before the debugger console is invoked? After 100 or so such messages,
> the emulator stops working anyway due to console traffic.

Thomas or Laurent, you've been involved with MMU emulation and
that THROW/CATCH stuff, could you look into that?


> It would be _really_ helpful to have a debugging mode in the emulator
> where any error exception will immediately switch to he debugger
> console, as would a non-emulation debugger. It really reduces the effort
> needed to trace rare freakout cases like this. I already understand this
> doesn't add value in terms of pure emulation - but it's valuable for the
> debugging use-case. Perhaps some existing args to Hatari will already do
> this?

Exception debugging option currently works only for oldUAE CPU core,
and only that has the double bus error check which pauses emulation.
IMHO those were very useful also for WinUAE core.

Btw. Exeption debugging option in oldUAE CPU core invokes debugger only for
address, bus and uninitialized exception handler errors.  I don't know
why it's not enable for other exceptions.


> (I am currently trying to recover my ability to build Hatari under Cygwin
> (new machine, new Cygwin, new SDL, new Hatari source etc... pain!) so
> changing the source isn't possible for me just yet. But I realise that I
> may have to do this myself once I know how)


	- Eero