Re: [hatari-devel] Debugger GUI enquiry

On Wed, 13 May 2020 at 22:41, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

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 https://pasteboard.co/J7VKUw5f.png) 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
else?

> 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

> cheers
> Steve
>
>
>
> On Mon, 11 May 2020 at 11:27, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
>
>> Hi,
>>
>> 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
>> the
>>> main loop and route DebugUI via the control socket, not the
>> implementation
>>> 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.
>>
>>
>>> However,
>>> 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)
>> blitter
>> 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 /
>> down).
>>
>> 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
>> debugger.
>>
>>
>> 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
>> pc=xxxx).
>>
>> 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
>> breakpoint.
>>
>> 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
>>
>>
>>
>