|Re: [hatari-devel] Debugger GUI enquiry|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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:
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
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
To me it seems that GDB stubs are better match for