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

Hi Thomas,

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

Ok that's useful information on its own, and might explain a few other things.

Would the debugger still be expected to hit my breakpoint, when I use something like this:

b pc=($8)

...and then $8 changes before the fault occurs?

I'm not sure if that command inspects $8 on every operation, or only once at the time the breakpoint is first set? I think the former, but not sure.

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.

Ok, so writing to ROM.. unmapped memory... etc. I should expect both the usual response from the emulated machine, and an additional response from Hatari because the operation may be unusual for a working program?

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

I can imagine not wanting the debugger console to appear due to TOS booting normally, even while in a debugging cycle. However what I am experiencing is somewhat more frustrating for a debugging cycle - the console is *not* appearing when a real crash is occurring. The core problem is just compounded slightly by an endless stream of crashing/messages which usually requires Hatari to be terminated.

In most cases like this I can intercept by breakpointing ($8) or so, but usually only if I'm making an effort to wait for the bug. And sometimes I could breakpoint ($8) but could be unlucky and it hits an illegal instead (only then realizing it's not a trivial bus error, and restarting the session). If it happens randomly, it could happen when I'm not debugging it - in fact *usually* when I'm not debugging it :-). This is where it would be useful to have a 'debug watch' mode of some kind, which brings up the console on the first 'error' type of event to occur - anything bad you'd want to know about while testing. All developer-kit debuggers I have used can behave in this way, usually by default (although, clearly that default is not what you'd want for an emulator!).

Perhaps this is best done with a script which sets a lot of different breakpoints, but even then I find it uncomfortable to always land in ROM, instead of my own code or something relevant, having to take more steps to get back there. This is a more minor point since it's just a few extra steps - but it does add inertia. The CPU history makes locating the cause easier, but can't be relied on because again it's off until you think you need it! It's also too shallow in the public release (although I can increase it for my own build)

The error message may report the cause address - but it depends on the message. A bus error just reports the read/write address from what I can tell, which requires inspecting the stackframe to find the likely cause.

All of this taken together means inertia, which increases almost exponentially as the type of bug gets more erratic or evil with corruption effects.

Being able to configure which types of exception invoke the console (as early as possible after the event) would make a big difference I think.

I'm sure some of this is a matter of learning to use Hatari debugger better, getting hold of more details and examples - but I think some of it is due to it not really being targeted at programmers writing new code, and more towards investigating existing programs which already work, to assist with improving emulation etc. I think the Hatari authors are the best people to figure out which is which... maybe writing my experiences will help with that.

(As an aside - the type of bug which caused these strange effects appears to be a stack/recursion overrun, walking into/across low memory and changing the exception vectors on the way. I didn't find this via breakpoints or error conditions - but by tracking the movement of the stack pointer and monitoring its depth at runtime. I think I would have diagnosed it more quickly with a better understanding of the original (relevant) error messages - but also think it could have been easier to collect information with a more immediate/certain response from the debugging console on the times it did occur).

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

I am not sure that MMU is involved at all. I would be more suspicious if I found that the debugging console/error messages were behaving abnormally for me - but it's probably just down to interpreting them properly.

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

That would be great, thanks.

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.

Of course - I wouldn't want to have that effect in any debugger. But I would like to be able to configure Hatari to behave like a programmer's debugger as well as an emulation-mode debugger, and respond helpfully to unusual events without much manual intervention while using it. It may just be a case of making a small script and and launching Hatari with that script - but it may not be, which is why I have outlined the scenarios above to add some colour.

Thanks for responding to my questions! Hatari is an amazing tool. I use it a lot and I send these messages only because of that.

Best,

Doug