|Re: [hatari-devel] Re: Hatari debugging help with WinUAE CPU core|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 19 tammikuu 2014, Douglas Little wrote:
> 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
It checks that on every executed CPU instruction.
When using these, it would be checked only when breakpoint is set:
(PC "address" command does immediate evaluation for its args,
and "" can be used to do it for "breakpoint" command too.)
You can see what is executed for every instructions from the response
of that command:
> b pc=($8)
pc = ( $8 )
> b pc="($8)"
pc = $2fc0b0a
> a ($8)
pc = $2fc0b0a
> 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.
It's pretty trivial to add a command line and config option for selecting
what exceptions should invoke debugger, something like this:
-D --exceptions bus,address,illegal
I'll do that next week, and change the current exception debugging
stuff to use the new variable. However, I may need some help in getting
oldUAE and WinUAE cores to trigger debugger on additional exception
types, than what -D currently supports.
> > 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.
With above, "--exceptions <list>" option would specify what things
will invoke debugger, and "-D" option  would toggle that set on
and off. Normally you would probably specify the set in command
line and enable catching then in debugger like this:
> setopt -D
(As TOS causes some exceptions at boot for HW detection.)