Re: [hatari-devel] debugger help

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 10 helmikuu 2014, Douglas Little wrote:
> Thanks for the detailed answer. I'll absorb the additional information
> you linked below.
> 
> I think the single biggest improvement which could be incorporated into
> the debugger for stepping/tracing purposes is a step command that
> executes until the next logical instruction at the same processor
> exception level. This would allow 'next' stepping with impunity, across
> conditional branches, loops etc. and without interrupts interfering at
> random (or not so random ;) times.

"next" command should actually do that.  It runs code until PC is
on next address, from the instruction on which you currently are,
it doesn't care what happens in between.

Compared to other debuggers, this might have a bit unexpected results
when done on RTD/RTE/RTR/RTS:
			0x1234  RTS
next ->		0x1236	JMP 0xfoobar

:-)

	- Eero

> However I'll learn what I can about using the existing features for next
> time.
> 
> D.
> 
> On 9 February 2014 19:12, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > 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