Re: [hatari-devel] Most wanted debugger/profiler feature or convenience?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 11 huhtikuu 2013, Douglas Little wrote:
> What's your most wanted debugger/profiler feature or convenience?
> 
> I'm not sure if the 'dspinfo' thing was added to show DSP stack state?
> This is definitely useful.

Yes:
-----
> info dsp 
DSP core information:
- SSH stack: 0000 0000 004e 0000 0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000
- SSL stack: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000
- Interrupt IPL: 0003 0003 0003 0003 0003 0002 0002 0002 ffff ffff ffff ffff
- Pending ints:  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
- Hostport: 00 12 06 0f 00 00 00 00 00 00 00 04
----


> LEDs to show HW activity can be handy, because if they remain ON when the
> program stops you have something like a clue to what was busy. The
> problem will be identifying which ones add value to a debugger.

Hatari statusbar doesn't have space for multiple LEDs, so the current
LED needs to be shared.  Disk access is probably only thing that users
expect it to be show, so it should be configurable what the LED is
showing.

First I would like a list of all things that the LED should ideally show,
preferably with some information about how to detect it... :-)


> A short queue/history for for DSP HOST port exchanges would be
> interesting (port data & status).

How short?  Could it be fixed size (e.g. 20), or does it need to
be configurable?

> That's pretty useful since loss of sync is a source of lock-ups. If one
> processor stops, it's interesting to see what pattern led to that. If
> the data, op (R/W), status were all side by side for each entry, you'd
> be able to see if data was written at some earlier point when the port
> was not ready, etc. (Note: flag state exists on both sides of the port
> and due to buffering, might not always agree)

Laurent, maybe you could help a bit with this, as I guess this to
be useful also for you? :-)


> A status flag showing when the blitter gets in activated in HOG mode vs
> non-HOG can help find blitter bugs in code which uses mixed modes in lots
> of places (like a game). A status query in the debugger for addresses
> which activated the blitter in each mode would be useful here.

Note that Hatari already has support for tracing Blitter control register 
writes ("trace blitter" in debugger, "--trace blitter" on cmd line).

If you want to see HOG mode changes at real time, set a tracing breakpoint
for it [1]:
	b (0xff8a3c).b & 0x40 ! b (0xff8a3c).b & 0x40 :trace


But should I add "info blitter" command to get all Blitter register
values (src, dst, control, skew, halftone etc)?


[1] Here's how many times that bit is flipped during Paradox's
	Pacemaker demo:
----------------
.....
1. CPU breakpoint condition(s) matched 422 times.
        ( 0xff8a3c ) . b & 0x40 ! ( 0xff8a3c ) . b & 0x40 :trace
  $ff8a3c = $40
1. CPU breakpoint condition(s) matched 423 times.
        ( 0xff8a3c ) . b & 0x40 ! ( 0xff8a3c ) . b & 0x40 :trace
  $ff8a3c = $0
----------------


> Another useful thing for blitter problems - having the debugger
> notice/alert when the blitter HW registers (other than busy bit) are
> modified while the blitter is running. That's usually a disaster, and can
> be hard to find (Far better avoided in the first place with tidy code,
> but then why do you need a debugger? :).

I guess there could be a warning message about this, if that really isn't
something that shouldn't happen.   Otherwise it should be a DEBUG messages
that isn't shown at default log level.

Nicolas is probably best to comment on this and add it.


	- Eero