Re: [hatari-devel] OT: My dream about Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 16 heinäkuu 2013, Miro Kropáček wrote:
> So this is my last appeal to you, please implement a debugger into
> Hatari, a real debugger with stepping, changing values (regs, memory),
> automatic symbol names (it's not there yet but I plan to import them
> from .LOD files, it's super easy) ...

Except for the UI, Hatari's current debugger has a lot more advanced
functionality than that, and for conditional breakpoints, I don't even
know how one would do mouse interaction for it in GUI.

Interactivity needs screen based UI (whether graphical or text based),
portable line-based UI isn't that nice for interaction.  IMHO Hatari's
debugger is nice to use for automating debugging & profiling though.


For example, currently Hatari debugger & profiler can automatically
profile CPU & DSP activity for worst frame in a game *while* you play it,
and automatically quit Hatari when you die (so that some extra scripting
can then automatically post-process the profile data).

In Doug's Bad Mood this is achieved with following bit of debugger
scripting ("r_begin" is symbol for frame start and "_P_DeathThink"
is called when player dies):
-------------------------------
symbols doom.sym text
dspprofile on
profile on

b pc=r_begin && CpuInstr > CpuInstr :trace :file profile-worst-save.ini
b pc=r_begin :trace :file profile-worst-clear.ini

b pc=_P_DeathThink :once :trace :quiet :file profile-quit.ini
--- profile-worst-save.ini ---
profile save worst-frame-CPU.txt
dspprofile save worst-frame-DSP.txt
--- profile-worst-clear.ini ---
e CpuInstr
------ profile-quit.ini -------
quit
-------------------------------

This will at start of every frame check if previous frame took more
instructions than any of the earlier frames and if it did, save its
profile (over previous save file).  After that check, it will clear
profile & debugger state for next frame.


NOTE-1: per-frame profile data clearing breakpoint needs to be set up
*after* adding worst-frame profile data save breakpoint.  If clearing
were done before, profile wouldn't contain any data.

NOTE-2: to clear profile data, it's enough to break into debugger to
load an empty profiler script, but script above will show also frame
instruction count. :-)

From the profile data Hatari's post-processor can then create things
like DSP callgraphs with number of cycles used by each function (and
anything it calls), CPU instruction cache miss callgraphs etc.


If you need callstacks for some specific function while
the program is running, enable profiling at the beginning
and setup following kind of breakpoint:
-----------------------------
b GemdosOpcode = 0x3F :quiet :noinit :file profile-backtrace.ini
--- profile-backtrace.ini ---
profile stack
b pc="NextPC" :once :quiet :noinit :file profile-d0.ini
------ profile-d0.ini -------
e d0
-----------------------------

Above will show backtraces to all Fread() calls and print
their return values.

If you set it up right when program starts, and don't break into
debugger in the meanwhile, backtraces go up to "main()".

Note that you see in backtrace only functions that:
- are called with JSR or BSR (or corresponding DSP instructions
  if you're profiling DSP code), functions called with BRA or JMP
  are not shown.
- have a symbol in symbol data you loaded before starting
  profiling.


> UI (mainly UI ;)
... 
> it really takes only two weeks and it would help me a lot
> (because my debugger has several limitations of course, no
> interrupts for example) and I'm sure not only me.
> 
> Sorry for such a long post but I just wanted to show you that something
> which might seems as a b***h work can be actually pretty simple to do.

Adding some breakpoint support (like stepping) to Hatari (Python) UI
would need quite a bit of work because currently Hatari's remote API
is pretty one-way.

Adding DSP support to Python UI (to same level as its (primitive) CPU
support), would probably be as much work.


But if showing the disassembly & memory & reg contents in pretty boxes and
supporting stepping are the main uses for such a thing, somebody writing it
as Qt code that gets called instead of the current DebugUI() function could
be a reasonable smallish (couple of weeks) amount of effort.

When it would be done work as a separate, modal window (similarly to how
Hatari (SDL) options dialog interacts with Hatari), one would also avoid
the tricky Qt & SDL interaction issues one would run into when trying to
convert whole Hatari into Qt program (which I've discussed in a mail on
26.11.2012 15:36).

Any volunteers?


I can help with that, but currently my time is limited mainly to answering
questions on how such functionality could be integrated to Hatari.


	- Eero