[hatari-devel] Steem debugger features not in Hatari debugger

[Nicolas Pomarède]

Le 03/06/2011 08:28, Eero Tamminen a écrit :
>>>     - Run for N cycles
>>>       (Hatari continue command accepts only instructions, not cycles)
>
> Would the last one be useful?

Depends on the user :) But stopping after >= N cycles elapsed should not 
be that hard.

>>>     - Monitoring reads&   writes to specific address.  Hatari supports
>>>       only monitoring changes to values, not having breakpoints
>>>       of reading values or writing the same value
>>
>> Not supported in current Hatari and quite time consuming, because it
>> requires evaluating "memory access" breakpoints on each read/write to
>> memory.
>>
>> I have a modified version that does this for my own debugging need, it
>> could be possible to add some proper hooks in the corresponding memory
>> handling functions,
>
> Could you mail the patch doing this?

I don't have a real patch ; just some hardcoded "if" + specific 
addresses, so nothing that can be put in production for now.
We'll see after 1.5 is out :)


>>>     - Showing breakpoints in instruction dumps.  Hatari breakpoints
>>>       are more advanced than the trivial address breakpoints...
>>
>> We can show only PC breakpoint in that case, but it's sure Hatari syntax
>> is more advanced than Steem's ont.
>
> To show PC address breakpoints in disassembly, the code would need to
> separately[1] keep track of address breakpoints.  In that case I guess it
> would make sense to revert the change where I made them to be just
> a wrapper for conditional breakpoints.
>
> This would require changing also the 68kDisass.c code, as breakpoint
> indication being on its own line would look horrible.
>
>
> [1] One more reason for this is that I assume there could be quit
> a lot of these breakpoints (especially if they're easy to add from an UI),
> whereas number of conditional breakpoints is quite limited and they're
> slower to check.  Address breakpoints can be binary searched from an array.

Yes, there could be 2 categories of breakpoints. Even in current CLI 
debugger this could be better for performance to have "simple" PC 
breakpoints in one list, and more complex breakpoint in a 2nd list.

>
>
>>>     - Adding new symbol names for arbitrary addresses one at the time.
>>>       Hatari debugger currently requires new symbols to be added to
>>>       a file containing all the symbols + reloading that file
>>
>> Can't say, I don't use that.
>
> I think UI makes that kind of reverse debugging much more convenient as
> you can easily annotate the disassembly as discover what it does.  To make
> it really useful, it would require this symbol information to be savable
> and Hatari to warn if it isn't saved at exit time...
>
> (The way how I have used the current symbols functionality is utilizing
> the symbol information generated by the AHCC compiler/linker.)

Yes, in that way it could indeed be interesting to "comment" the disasm 
code and have these infos saved in a kind of "debugger snapshot" (I 
don't think it should be saved in the "memory snapshot")

>>>     - Stack content display
>>
>> Should be in the "easy" section I think, it's just a dump of the memory
>> before the value pointed by A7.
>
> You mean it would be just:
> 	m "a7"
> ?

m "a7" will display bytes at a7 and more (incrementing). But when you 
want to display the stack you must decrement. For example do something 
like (don't know if this syntax works) :

  m "a7" - $20

Which would display the last 32 bytes before the content of a7

>
> But with a bit different output; instead of 16x hex values per line,
> a word as 2x hex, 2x ASCII&  decimal&  binary values.  (I.e. using
> same output routine as I mentioned above)

It's hard to know if the data in the stack are words or longs, so you 
have to pick one format to display them, but there're no rule.

>
>
>>>     - Shift Atari screen contents by 0/2/4/6 bytes
>>
>> Not very useful, only use is when trying to debug overscan's emulation
>> problems, but Hatari is now fairly robust.
>
> I guess it's mean for people debuggign their own code, not the emulator
> itself.  :-)

Yes, and even so, I think the coded can easily do this in his own code.

>
>>> (I think rest of the Steem features can be supported by the Hatari
>>> breakpoints.)
>
> Steem actually has one more thing not possible in Hatari:
>       - Setting a breakpoint on an interrupt
>
> Any suggestions how to best check for interrupt?
> (I mean, how to express it in breakpoints syntax)

Each interrupt in calling Exception() in newcpu.c with and exception 
number and and exception source (cpu, mfp). Adding a condition on the 
expception number allows to catch any kind of interrrupt.

> (Only potential small usability downside from working through remote API
> would be this 0.1s delay per view before it gets refreshed that I mentioned
> earlier.)

I think this 0.1 delay would be really annoying when trying to fast 
scroll pressing page down for example in a memory dump window.

That's why I think an infrastructure that would allow to add several UI 
inside Hatari (depending on the compile time options) would be better, 
as it would bypass any inter-processes communications and the possible 
latency introduced (not counting the required formatting needed to 
exchange data in a parsable way).

>> And a way to search for hexa/text in Hatari's RAM.
>
> This needs a new feature in the internal debugger too.

I think it could be added rather easily in the current debugger ? Maybe 
with some optional start/end addresses (to search in ram or in rom for 
example).
With the ability to search for several bytes/words/longs at the same time.

search $0-$3000 $1 $45 $1234

optional range is in the form x-y ; if not present defaut to a search in 
the whole ram.

values' size is determined when parsing each value. For example the 
above would look for a byte $1 followed by a byte $45 followed by a word 
$1234.
We could even add text string in the search pattern :

search 'tos ' $45 $18 'atari'


Nicolas