[hatari-devel] Execution history debugger command

[Nicolas Pomarède]

Le 29/05/2011 00:43, Eero Tamminen a écrit :
> Hi,
>
>> Btw. I was thinking of adding a "history" command to Hatari debugger, with
>> which you can set how many instructions back the debugger will remember
>> execution and be able to show previous values.
>>
>> For first I was thinking of storing just the PC to backtrack branches that
>> have happened e.g. before a breakpoint (without flooding the console like
>> disasm trace does), but it could later store also all CPU registers and
>> anything else you might be interested about...
>
> I already did a quick implementation of this as its own command:
> ------------
>> dsphistory
> DSP history isn't enabled!
>> dsphistory 8
> Enabled and allocated 8 items for DSP history.
>> c
> Returning to emulation...
> SPEED: 146.1 VBL/s (558/3.8s), diff=-48.2%
>
> CPU=$e09b5c, VBL=1227, FrameCycles=70, HBL=0, LineCycles=70, DSP=$51
>> dsphistory
> Last DSP PC positions from oldest to latest:
> 8. $0451
> 7. $0451
> 6. $0451
> 5. $0451
> 4. $0451
> 3. $0451
> 2. $0451
> 1. $0451
>> dsphistory 20
> Changed CPU history size from 8 to 20.
> ------------
>
> but I started to wonder how it should actually be used...
>
> Should CPU execution history be tracked always so that debugger just allows
> changing the ring buffer size for that and showing the result, or should it
> be always specifically enabled in debugger?  (when it stores also something
> else on every instruction execution)
>
>
> Or what if it would be part of the profile command?
>
>
> One more possibility might be storing the history only for branches.
> I wasn't thinking of checking the instructions themselves, just whether new
> PC address differs more than "limit" from previous PC address.
>
> The PC offset limit could be something that user sets, so one could use it
> e.g. to catch:
> * all last N instructions with value set to 1
>    (for seeing tight loop repeats without knowing about loop counter value)
> * only jumps to ROM&  back with value set to large enough number.
>
> What do you think?
>

Hello

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.
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.

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.
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).

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.


Nicolas