|Re: [hatari-devel] Debugger GUI enquiry|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Debugger GUI enquiry
- From: Steven Tattersall <steven.tattersall@xxxxxxxxx>
- Date: Thu, 14 May 2020 09:32:12 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Tp5AwNps5kv3pVMd/RyDzRB/B7+os0Hmi0iOCBvBm8U=; b=aiOipvau9FJSgjM7VMX1vircH6YoIkkkmhZcXrs1WEQZt0Owifw5KVxlDY1fwGqWBV AHcPQe1o8pA8sMlE+F0EzgcTuuGcXDRDSO/7IeRN5Zur2eARm/CdKG23j9k2QhejYXTK XSwjdSf1yfZC0/aelU0tvtktokDUjE/rjI5D1smegWUqlvYCCD1cPUma5R82nOdt+V01 jzsWs+XHcL8GHyHgzI/UXapyRsNaZRUroSbNDTdwwctln6tteP1vuuq9dH2zInFzPLaw WaFPpJEWAZkk78PD9ndlHX6E8ne+32PA/1JVBYivOcwfT/7EwH4ZKDXKsgqHjnuoNzFE MVSQ==
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 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?
> - 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 ,
by doing blocking read. But please send more
complete patch first.
 Hatari should already do that while it's
> - 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
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.
> 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