Re: [hatari-devel] Debugger GUI enquiry

[Steven Tattersall <steven.tattersall@xxxxxxxxx>]

Thanks everyone.

It sounds like the best approach is for me to work on simply getting a basic remote-debug process working, with a sensible protocol that can be extended (I've found the gdb spec helpful as a guide), then present that as a patch.

Currently I am using the existing control sockets as the input feed; there might be a couple of things I need to add there to prevent commands being lost when Control_CheckUpdates() exits, but it sounds better than adding a new socket at the moment.

In terms of the GUI framework, I'm still using the Python Gtk code as my testbed to make sure the concept works. If the debug process is solid, it shouldn't matter too much what GUI/language framework is used. I'm sure we all have our preferences.

The patch might take a while for me to get to a stage where I'm happy, so don't be surprised if I "go dark" for a bit.

cheers

Steve

On Fri, 8 May 2020 at 09:49, Thomas Huth <th.huth@xxxxxxxxx> wrote:

Am Thu, 7 May 2020 21:50:10 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
>
> On 5/7/20 7:22 PM, Thomas Huth wrote:
> > Am Thu, 7 May 2020 10:33:48 +0100
> > schrieb Steven Tattersall <steven.tattersall@xxxxxxxxx>:
> >   
> >> Thanks Eero, thanks Nicolas.
> >>
> >> It seems like there's some debate about whether using remote
> >> process debugging is want you want. I did have to jump through
> >> some hoops to get single-step working, and I didn't yet do full
> >> breakpoint/stop detection. Obviously exposing remote debug is very
> >> powerful if the interface is right, and it means I could develop
> >> the tooling without tinkering with the core Hatari codebase too
> >> much. On the other side, that might be over-engineering it, when
> >> something simpler might do the job. 
> >
> > Not sure whether it's really feasible, but just an idea: Implement a
> > GDB-compatible stub. That's e.g. also what QEMU is doing (so you
> > might be able to get some inspiration there), and that way, also
> > other debuggers that know about m68k can be used. 
[...]
> And how GDB stub remote debugger would support
> debugging both CPU and DSP at the same time,
> by having 2 separate connections & debuggers?

Hmm, right, I didn't consider that. So never mind, a GDB-stub is likely
not the right solution here.

 Thomas