Re: [hatari-devel] 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:

Great! :)

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.

I'm not sure how you can share a LED for multiple things, as it loses its value then? Except as a flashy thing in the corner. Perhaps I'm missing something.

TBH there will always be better ways to diagnose something than via a LED so it may not matter much.

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

Good question. I think something like 20 would be enough to be useful. Making it deeper can't solve problems where a block is several kwords in size and the fault happened near the start, and surfaced near the end. Nobody would search through that much history anyway, unless the debugger did sanity checks on the history itself (which is another possibility - some common faults are detectable)

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

That's cool. I didn't know.

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

Ideally it would be a breakpoint/debugger exception event which needs turned on - since it's interesting when it happens to code you're writing, it's not so interesting when it happens in somebody else's program.