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

[Eero Tamminen]

Hi,

On torstai 02 kesäkuu 2011, Nicolas Pomarède wrote:
> Le 02/06/2011 20:27, Eero Tamminen a écrit :
> > Steem debugger's features which are missing from the current
> > Hatari CLI debugger:
> > 
> > * Things that would seem to be straightforward to add:
> >    - History.  I would need to add tracking also instruction cycles
> >      to the code I posted earlier
> >      (= Steem History view&  Trace info)
> >    
> >    - Showing values both in different lengts and numeric bases.
> >      In Hatari one gets latter with "evaluate" command, e.g. "e a0",
> >      but that doesn't show the value if it were long/word/byte
> >    
> >    - All register values being shown with above info
> >      (= Steem Register monitor)
> >    
> >    - info commands for PSG, MFP, FDC and IKBD register values
> >      (= Steem monitors for these)
> >    
> >    - Info command for "timings" i.e. cycles since HBL/VBL, timer
> >      values, video address&  scanline
> >      (= Steem Timings view)
>
> regarding the reg/timer/monitors/dump view, it's of course possible do
> use the "info" command already available and add more output to it.

Yep.  And with the "lock" command you can make it to be shown every time
you enter debugger.  If you want tracing breakpoints to show that
information too, use the ":lock" breakpoint option instead of the ":trace"
option.

(These options are briefly explained in the manual.)


> >    - memory dump in text format
> >      (= Steem Text monitor)
> >    
> >    - Text string and binary values (hex) search
> >      (= widgets in Steem monitor windows)
> >    
> >    - Disasm format options being changable at run-time
> >      (= Steem options)
> >    
> >    - Run for N cycles
> >      (Hatari continue command accepts only instructions, not cycles)

Would the last one be useful?


> > * These would be harder, either because I'm not sure where/how these
> >    would be best integrated or because they're more work:
> >
> >    - 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?


> but we would also need to add a #define to enable
> this kind of memory breakpoint at compile time, because it can really
> slow down performance and not everybody needs it.
> 
> Still, this is the most useful we miss in my opinion, it's really
> powerful to monitor some memory location and I sometime use Steem just
> to see what part of a program accessed such memory region.

Ok, that's a good reason to add it to Hatari (as compile option). :)


> >    - Break on exceptions 2-8 vs. bombs vs. don't break.
> >      Hatari has only an option to break on address&  bus errors
> >      &  uninitialized exception handler.
> 
> Not sure this is important. In games/demos, you most likely want "don't
> break" because it often part of the protection to do such behaviour.

OK.


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


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


> >    - Memory dump that shows also disassembly and values in
> >      different bases
> >      (= Steem Memory monitor)
> >    
> >    - 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"
?

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)


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


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


> > Do any of the above listed items (especially the easy ones) sound
> > interesting to be had in the CLI debugger?
> > 
> > (As I'm already listing missing Monst features as potential TODOs
> >   for Hatari debugger, I'll add these also to the todo.txt file.)
> 
> The info command for the different components can be useful, but it's of
> course more easy to use if you are in UI mode.

Sure.  But (remote) UI can use the info command output.


>> So... I think you need to specify quite in detail what you would like
>> to have in the debugger GUI and in which priority order before it
>> makes much sense to start coding it.
> 
> Well the ability to open as many dump/info windows as wanted
> (hex/asm/mfp/video/sound/...) and have those content refreshed each time
> a breakpoint is encountered would be nice.
> 
> A stop/run button, as well as a "execute only instruction" buttons would
> be cool.

These seem as easy to do through the remote API as without, after I've
added to remote API a facility to notify the client about breakpoint hits.

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


> The possibility to click to define simple PC breakpoint (or monitor
> memory on B/W/L accesses)
> 
> And a way to search for hexa/text in Hatari's RAM.

This needs a new feature in the internal debugger too.


> At least, that what I use the most ; other people might have different
> needs.

Hopefully the others pipe up if they have something else that they
use more commonly.  :-)


Thanks!


	- Eero