Re: [hatari-devel] Debugger GUI enquiry

[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.

I found Python code for interfacing with Gdb stubs:
	https://github.com/stef/pyrsp

It seems to parse ELF files and symbols by itself.

If even that needs to be done on the Python side
i.e. such info can't be transferred over stubs,
this would mean that remote program can't rely on
90% of the current Hatari debugger functionality.


While stop/cont, reg and memory values can be fine
for primitive low level debugger, you would loose
*a lot*.  It would e.g. be completely unsuitable
for debugging large programs like BadMood, Quake
or ScummVM.


Hatari debugger e.g. supports backtraces by its
profiler tracing all executed instructions and
matching them to loaded symbol addresses.  This
isn't something that can be done over socket
(for obvious perf reasons).

Because Hatari profiler/debugger doesn't need to
do any stack unwinding, backtraces work regardless
of whether the code is built with frame pointers /
unwinding information, or not.

Atari binaries don't contain unwind info.

=> If one would e.g. want to use DDD with Hatari,
that would probably work with all features only
with ELF binaries.  In m68k case that would
probably mean just Linux kernel.


And how GDB stub remote debugger would support
debugging both CPU and DSP at the same time,
by having 2 separate connections & debuggers?

While an already existing remote debugger may
support m68k, is there something supporting
56001?


To me it seems that GDB stubs are better match for
Aranym...


	- Eero