Re: [hatari-devel] debugger help

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 07 helmikuu 2014, Douglas Little wrote:
> One of the most common accidents I have while debugging with Hatari, is
> landing in interrupt code while single-stepping to inspect context for a
> bug.
> 
> For a start, breaking into the program/debugger using they keyboard
> shortcut (F10 in my case) seems to queue up at least one interrupt which
> occurs on the very first single-step operation. This can't be just bad
> luck because it happens nearly every time I do it. There's something
> strange about this behaviour - I'm just not sure what!

Hatari processes all of its keyboard input during emulator's VBL wait,
but I'm not sure at which exact point at VBL processing this happens
(Nicolas?), and whether it's done at the same way with both old UAE and
WinUAE CPU cores (Laurent?).

Have you noticed any difference between the CPU cores in this respect?


> So to get around this I have a rather tedious procedure each time I break
> in - set a breakpoint ahead of the break and continue, to soak up the
> pending interrupt so I can start stepping. e.g.
....
> This is lengthy (and error-prone) to have to do every time I want to
> trace code, especially if looking for a bug and having to repeat the
> same process several times. It's not unusual for me to make typos on
> repeated sequences of commands or keys, and have to restart.

There are several ways on how to proceed:
- add breakpoint and continue
- give instruction count to "continue"
- use "step" to step through the code
- use "next" to step and skip subroutine calls
- use "next <instruction type>" to run until certain type of instruction.
  e.g. use "next exreturn" / "dspnext exreturn" to run until RTE

For more info on last one, see the section I just added to manual:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
file/tip/doc/manual.html#Stepping_through_code

(or read "My dream about Hatari" thread started by Miro. :-))


> I'm also not sure if there's a nice easy way to prevent this kind of
> thing generally - like a 'step' command that steps until the next
> instruction at the same processor exception level, rather than the next
> instruction literally. Again this is something that doesn't seem to
> occur in a normal debugger - probably because there are several types of
> stepping command (step next, step over.. etc) with more complicated
> logic behind them.
> 
> Typically the 'step over' in a debugger will execute subroutines and
> interrupts, but understands branches/loops. e.g. it stops not at the next
> sequential address but rather the next sequential instruction at the
> branch target - which prevents accidents like completing a loop vs
> stepping back to the loop start.

"Next" command is just shorthand for setting a "quiet" breakpoint
and continueing.  Step command is shorthand for "continue 1".

I guess something similar could be added for step over.  First it
would require adding debugger variable for interrupt mask/level,
and some proposal on what syntax such a command would have.


> The trouble with relying on manual breakpoints to aid single-stepping is
> it takes a long time to enter them, and eventually leads to user error
> (setting wrong address by eye etc.).
> 
> I'm probably missing something important here, so please enlighten me :-)
> Is it something that should be done by writing scripts?

No.

Scripts are executed within current debugger invocation context,
they cannot do continues, or span across them.


> And can such scripts be generic enough to be used as stepping commands
> for any typical program, or is scripting mainly to accelerate one specific
> scenario when dealing with one known bit of code?

Scripts are intended to automate any sequence of debugger commands that
can be done within *same* debugger invocation.   Currently they seem
most useful for automating things when:
- starting Hatari
- entering debugger
- hitting breakpoint

Which can be used to automate quite a lot of things by chaining breakpoints.

If your problem is fully reproducible, you could incrementally create
a breakpoint chain that finds the issue.  Different breakpoints in this
chain can enable & disable traces (disassembly, OS calls, IO register
accesses etc) and output other necessary information (register & memory
dumps) that help you finding how to chain next breakpoint, until you've
identified the root cause.

In BadMood case, because the loading takes so much time, I would suggest
starting by creating a memory snapshot from situation just before the issue
starts.


	- Eero