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.
cheers
Steve