Re: [hatari-devel] Exception debugging?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On tiistai 06 marraskuu 2012, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > Thomas, why Hatari exception debugging breaks into debugger
> > only on some specific exceptions, not all of them, and could
> > that be fixed?
> 
> You mean the way that the DebugUI is called when a program hits an bus
> error or address error?

Yes.  All debuggers have this feature and in Steem it's even configurable
which exceptions invoke the debugger.


> That was just a quick hack in the past for
> debugging certain programs. Which other exceptions do you have in mind
> that could also drop to the debugger? I don't think it makes sense to
> really add _all_ of them...

The normal trap ones of course shouldn't invoke debugger,
but everything giving bombs in TOS should.

This is the list of them on ST, from my MONST2 manual:
2. bus error
3. address error
4. illegal instruction
5. zero divide
6. CHK instruction register bounds check
7. TRAPV instruction overflow check
8. priviledge violation
9. trace
32, 35-44, 47. unused traps #0, #3-#12, #15

If 030/040 CPUs have additional bombing exceptions under TOS,
the those should be caught too.


Trace exception is used by debuggers, so that could be skipped.

Illegal instruction exception should invoke the debugger only
for the illegal opcodes that aren't handled otherwise by
by Hatari (for VDI/AES, HD and NATFEATS emulation when
they're enabled).


Best would be to have some internal Hatari bitmask variable which
controls which exceptions invoke the debugger.  By default it would
be zero, and -D option would change the mask to catch the above
exceptions.

I could then add --exceptions option to specify a list of
exceptions that should invoke debugger; either as hex, or as
a list of exception numbers or names (similarly to --trace),
whichever way people here on the list prefer.


Or if catching all of above is too much work, at least catching
exceptions 2-8 would be great (then int suffices as bitmask
instead of long long).


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/