Re: [hatari-devel] Debugger GUI enquiry

[ Thread Index | Date Index | More Archives ]

OK, I deliberately didn't add the remote-debug command implementations that set those values in this patch, so that nothing can trigger it by accident :)

I'll do a patch tonight with something to set them (basically strcmp s for the moment).

I don't have any builds that use the FIFO, so am not sure what that involves. Conceptually I don't think it would differ from the socket approach. In general, if something can service external commands then call DebugUI_ProcessRemoteDebug with strings, it should work.

By "wait until remote debugger socket/FIFO has something", do you mean write a function different from Control_CheckUpdates() to read and process the incoming commands? Or do you just want me to set bRemotePaused before calling the function?

The UI is still the original Python/GTK at the moment. The more I use it, the more uncomfortable I feel with it, but since this is prototyping I'll see where it takes me.


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

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

> 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

Mail converted by MHonArc 2.6.19+