[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On keskiviikko 01 kesäkuu 2011, Nicolas Pomarède wrote:
> Le 31/05/2011 19:56, Eero Tamminen a écrit :
> > Would it be more useful to have the history saved on breakpoints
> > instead of what I proposed?
> > 
> > To get information on branches with those, I would need a new kind of
> > breakpoint that is triggered only on branches which offset is larger
> > than <limit>.  Would that kind of breakpoint facility be useful for
> > you too?
> > 
> > I guess best way to do that would be to have an internal debugger
> > variable which value = abs(previous_pc - current_pc).  Any suggestions
> > for its name?
> > 
> > :-)
> 
> Honestly, I never felt the need for some kind of "branch breakpoint", a
> problem is rarely related to branches only, you need the context of all
> instructions before and after the branch, which in fact means you need
> all instructions.
>
> Most of the time, when I want to debug complex problems, this can't be
> limited to tracking a limited history. At one point, I need to go back
> many VBLs in time, which means an history of 100000s instructions !

Hmm.  The things that I've looked lately have happened during several
seconds so there can easily be hundreds of VBLs worth of stuff to go 
through.  It's not really practical (at least to me) to approach that
through disassembly... :)


> So, my solution is to run "hatari --trace cpu_all", which basically
> gives you an history of all the instructions ; then I add breakpoints to
> the places that make sense to me and this allows me to narrow the field
> to the source of the problem by doing successive runs of Hatari.
> 
> With a rather long practice of asm, I think it's more efficient to get a
> full trace up to the point of the crash, do a first analysis of the log
> file, then add some breakpoints here and there and iterate.

With my limited experience with m68k asm it's easier for me to first limit
the amount of code to cover, add some breakpoints and only then start
reading disassembly.  I.e. do it from completely opposite direction...

With chained breakpoints that parse debugger input files, it's also now
fairly easy to have one breakpoint that enables tracing and another that
stops it.  With one more debugger input file to setup breakpoints at Hatari
startup (and memory snapshot if what you're after doesn't happen close to
boot), you can even automate this completely.


	- Eero