[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On sunnuntai 29 toukokuu 2011, Nicolas Pomarède wrote:
> in my long experiment of asm coding, I must admit I rarely missed a
> history. The problem is that if you only store registers (pc, ...) you
> will have an incomplete view of what happened, because you won't know
> what values were in memory at the time it was accessed.  And debugging
> code without having the associated ram values is more or less just like
> reading the source code without really executing it, which is something
> you can already do.

Where this helps is greatly narrowing out which part of the code you need to
read.

If you have a place where the issue happens, but code jumps to it from
many different places:
* reading code for a large program to find out where/why it happens is not
  very feasible
* if there are loops, disassembly output is just too verbose, and
* while with beakpoints it's feasible to track that, it can be tedious
  ("oh, now I need to set breakpoint for that and re-run this thing again")


> There, you have the registers and a history of what value were in PC,
> but I'm not sure it's enough to do something that really add extra
> values. Breakpoints are much more useful, and in the current state we
> have some rather good syntax to handle them.

It's not a replacement for breakpoints, but a helper for tracking back what
lead to triggering of the breakpoint.


> Of course, the problem is not to do it, but will someone use it in real
> case ? Honestly, I'm not sure it will be used.

I'm often using profiling to check where code gets stuck (is it looping
in some small part of code or all over the place in TOS etc).

History makes it easier for me to find out how the code ends up in that
tight loop without needing to set any breakpoints, then I can just
disassemble & read the code around places shown by profile & history.


> A lot of things can be added to Hatari regarding debugging, but we
> should stay consistent and focus mainly on emulation, I think the debug
> functions we have are largely enough (unless we have some feedbacks from
> users, which until there has not really been the case regarding the
> debug part).

That might be because Hatari hasn't had all features that native debuggers
have (and because some people don't like using command line debugger)... :-)


> There's a lot of potential things that can be made, but if it's just at
> the expense of code's growth and no one using it, I'm not sure it's
> interesting to add them just for the sake of doing it.

Well, I've actually been thinking of eventually adding most of Monst
features to Hatari...  History is one of these features (and it's on todo
list).


	- Eero