Re: [hatari-devel] Debugger GUI enquiry

[ Thread Index | Date Index | More Archives ]

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.

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?) 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.

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.


On Thu, 7 May 2020 at 09:04, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

On 5/6/20 10:37 PM, Steven Tattersall wrote:
> Hello splendid Hatari developers,
> I was wondering what the current plans are for Hatari are in terms of the
> graphical debugger UI. The existing hatari-ui python debugging UI doesn't
> appear to have changed much recently. I also suspect it isn't used very
> much, given that it doesn't offer services like single-step.
> I have masses else on my todo list, but I might be able to offer some free
> cycles to work on this, because there are some exciting possibilities if it
> works, (plus I've had a bit of experience making debugging tools in my day
> job.)
> To understand what's there already, I did some messing about, based on
> making small modifications to the existing python plus control.c and
> debugui.c, to get single-stepping and batched queries. But it's strictly a
> learning prototype and I don't want to tread any one's toes. (I know there
> was some discussion of using SDL2 for visualisation windows on atari-forum,
> for example)

I have no plans on extending current Python UI
this year, except maybe adding support for some
Hatari configuration options that it doesn't
support yet (are there any config options you

Doing UI debugger from a separate process is
clumsy enough that I've kind of given up on
the Python one.

But if you have ideas on how to improve and make
it more useful, I'm very interested to see your
patches.  Please send them to list for comments!

        - Eero

Mail converted by MHonArc 2.6.19+