Re: [hatari-devel] Debugger GUI enquiry

[ Thread Index | Date Index | More Archives ]


On 5/13/20 11:18 PM, Steven Tattersall wrote:
Attached is an early patch to try to hook remote debug command processing
into the existing core loop.

Thanks, but this patch is too incomplete;
besides initial values, nothing is setting:
- "bRemoteBreakRequest" to true
- "bRemoteBreakIsActive" to false

Could you send a more complete one?

Some notes:

- the idea is to jump in when DebugUI() is called and service commands from
the network socket. The code in control.c registers a callback into the
debugui system when it connects/disconnects.

In general this looks fine.

Do you think remote debugging would work also over FIFO? :-)

- it doesn't actually do anything useful yet -- the
DebugUI_ProcessRemoteDebug call is basically a stub, i.e. it doesn't
implement any useful commands yet. I have a local set of changes which
implements a system similar to the existing console debug commands, but
stripped down to handle the simpler cases of remote-debug, plus some
rudimentary implementations of disasm/memory/register commands.

No busy-looping please, I think you can wait until
remote debugger socket/FIFO has something [1],
by doing blocking read.  But please send more
complete patch first.

[1] Hatari should already do that while it's
    remotely paused.

- there are no changes to the Python UI in this. I have something running
(see a screenshot at at a good
interactive speed when single-steeping, but it's strictly a prototype with
no UI refinement or design, and the code is a mess.

Ooh, you have already multiple views to the same
Hatari instance!

Is it still done with Python / Gtk, or something

Anyway, see what you think. I've had a bad day at work, so be gentle :)

We had already kind of given this up as too
complicated, so I think it's really nice that
somebody's looking into this with fresh new ideas.

	- Eero


On Mon, 11 May 2020 at 11:27, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:


On 5/10/20 11:13 PM, Steven Tattersall wrote:
On Sun, 10 May 2020 at 10:08, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
I'm slowly getting there with an initial patch. To make it manageable it
will probably only contain the core bit where the hooks have to go into
main loop and route DebugUI via the control socket, not the
of test debugging commands or the python UI code. Should I send it to you
direct, or to the mailing list?

Just send it to the mailing list.  It affects
Hatari main loop so others may have comments on
it too.

What do you think of the idea of doing the disasm
etc output on the Hatari side in SDL2 window, and
just doing the control in the remote GUI process?

It would allow you some quite responsive update/refresh I think.

Using intermediate files for Hatari internal views
could be awkward.  So, all the related functions
would need to be changed to support writing to a
string buffer in addition to just to a given FILE.

That can be quite a lot of changes.

even views like disassembly would need to be interactive (for instance,
setting breakpoints) so I wonder if it would get quite messy trying to
arbitrate between external and internal GUI control?

Possibly. I think we need to flesh out a bit more
how it could or should work, both to make the
interaction most sensible to the user and for
code managing them.

How does following sound?

Register & HW info views (updated on every
debugger invocation) don't need any interaction,
assuming they're large enough to show all relevant
content.  So they can be controlled completely from the remote GUI.

In the debugger CLI, commands for controlling
them could be something like:
         view registers -> opens new view
         view videl     -> opens new view
         view list      -> lists supported views
registers (shown)
videl (shown)
         view rm registers -> removes view
         view rm all -> removes all views

As to interactive SDL2 views...

User will want to scroll disasm & memdump views,
and I think that's best done with direct view
interaction (using arrows keys and page up /

Setting what memory area should be shown whenever
debugger is invoked, should IMHO be done when
view is configured, but I think it should be
possible to re-configure interactive views without
needing to recreate them.

If view is already open, it will just jump to
a different address:
         view memdump <start address> [lines]
         view disasm  <start address> [lines]
         view dspdisasm  <start address> [lines]

(If number of lines changes, I guess view SDL2
texture needs to be recreated.)

List of debugger views and their options could
be one configuration dialog in the remote

As to breakpoints, I think all the direct user
interaction can also be done on the Hatari side
and remote debugger is just informed of what was
done on its behalf (breakpoint set/unset at

Remote debugger would then just have a window
with a list of current address breakpoints and
their options:
- checkbox: remove after triggering
- counter:  trigger every Nth hit

And highlighting for last triggered and/or set

It should be possible to delete breakpoints from
the remote debugger too, and remote GUI needs to
be informed of breakpoint removals done through
other means than the interactive disasm view.

Some users will want multiple (CPU & DSP) memdump
and disasm views, but I'm not sure whether they
should be supported.  If yes, view command needs
indexes for them:
         view disasm <idx> <address> [lines]
         view rm disasm <idx>

         - Eero

Mail converted by MHonArc 2.6.19+