| Re: [hatari-devel] Debugger GUI enquiry |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
Sorry for the late reply.
On 5/7/20 12:33 PM, Steven Tattersall wrote:
It seems like there's some debate about whether using remote process
debugging is want you want.
If it can be gotten to work well enough, without
needing to write same code both in Hatari and
remote debugger side, I would certainly prefer it.
While providing remote debugger also for Windows /
Mac would need somebody to actually support & maintain it for those
platforms, it gives much
more freedom for the GUI implementation toolkit &
language (personally I don't care if there's no
debugger GUI for Windows, as Windows has STeem).
One alternative would be to add to Hatari support
for configuring N additional SDL2 output windows
(for showing CPU & DSP register, dissasm, memdump
and output from relevant info commands), which
contents would refresh automatically when Hatari
emulation is paused.
Those could be used both by simple in-process
SDL2 debugger GUI (which would be the only thing
supported on Windows), and by remote debugger GUI
for faster output [1].
Remote debugger would just configure those SDL2
windows for its register, disasm and memory dump
outputs, and skip the in-process debugger GUI
control window.
How does that sound and has somebody experience
with using multiple SDL2 windows (are there any
gotchas)?
[1] Having just the (localized) GUI controls in
the remote debugger would certainly be faster than
parsing things over socket and rendering
monospaced ASCII with PyGtk.
I did have to jump through some hoops to get
single-step working, and I didn't yet do full breakpoint/stop detection.
That's the hard part I think. Once both sides
can invoke each other, breakpoint support follows
naturally.
I'm not sure conditional breakpoints are best fit
for GUI debugger though. If you want to show
breakpoints in disassembly output, and user to be
able to set breakpoint just by clicking on a line
in disassembly, I think there should be support
for real address breakpoints.
(Currently debugger "address" command is just
syntactic sugar for conditional breakpoints,
you can't list them separately. Adding real
address breakpoint support should be easy
though.)
You should also check debugger feature list in
doc/todo.txt.
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.
Perhaps I should outline some of the things I had to do, to get even the
rudimentary functionality. That might give some pointers as to whether
there is any point in me trying a patch for this approach. There might well
be much better solutions to these that I am not aware of.
1) Allow the central DebugUI() function to accept commands from the control
socket, rather than the console input. This allows it to actually do
debugging work when stopped after a break, single-stepping etc. It would
also need a mechanism to know when to use the control socket for input
(simply when something is connected to the socket?)
Yes, if something is connected to a control
socket, that should be in control of Hatari.
Plus it needs a command
mechanism to exit from the control socket and restart.
2) Rather than using the hatari-pause control function, add a control
function that simulated breaking in the same way as hitting the AltGr+Break
key, then detecting this break flag in VideoInterruptHandler_VBL like a
shortcut key. This was needed so that the first single-step actually
worked: the current call to Control_CheckUpdates() is in a different area
of the main loop, so there was a problem checking the number of
instructions executed before the break-to-console-debugger is initiated. It
might be possible to change where Control_CheckUpdates() is called in the
main loop, but I don't know whether that would affect something fundamental.
If you test it, and it works for you, I and
Thomas can check your patch for whether we think
that would break something else.
3) Add a couple of control commands, to allow the debugger UI to query
status like PC and check that the system was in "break" mode, and echo
strings back to ensure that the UI<->debugger link was fully in sync (so
that I could batch up requests for data to keep the UI speed reasonable.)
Generally I didn't make too many changes like this so far, but I'm fairly
sure that for a robust debug mechanism it would need some commands to
support a simple machine-parseable debugger protocol, rather than trying to
parse the current string output.
Even if Hatari process does the actual data output
for performance reasons, and remote debugger GUI
just controls it, it would still need to know the
current PC address.
And if (address) breakpoints are marked by
clicking on Hatari side SDL2 output windows,
remote debugger GUI needs to know that too,
so that it can control those breakpoints.
- Eero
PS. When I started the Python (debugger) GUI,
Hatari didn't support SDL2, and I had no idea
that it would support multiple windows...