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

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 12 Jan 2014 00:32:27 +0200
schrieb 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.

Right. So for example you get such a flood of messages when your
exception handler is crashing again, so it get an endless loop of
exceptions, one crashing after the other.

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

Yes, that's also debugging output by Hatari to show a bus or address
error.

The last number is the destination vector address - which is 0 in your
case! So something messed up the bus error exception handler.

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

It depends on the way the bus error has been generated. For accessing
bad IO memory addresses, it should print such an error. For certain bus
errors that are generated within the WinUAE CPU core, the message might
look different.

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

Well, the problem is, how do you want to distinguish this? The emulator
can hardly know what TOS is doing unless you want to create a huge
table that lists all hardware test addresses for all TOS versions.

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

Is MMU really involved here or is this just about "normal" WinUAE mode?

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

Yes, these error message floods can be pretty annoying... I'll try to
add a limit. 

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

If you enable the debugger for _all_ exceptions, you simply do get too
many of them. Interrupts occur quite often, and it's quite cumbersome
when you try to step through a program and always get interrupted by
such an event.

 Thomas