| [hatari-devel] Re: Hatari Debugger & GUI |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
(Nicolas, there's a question for too down below, just search your name.)
On 05/11/2018 06:35 PM, tin@xxxxxxxxx wrote:
I'm contacting you off-list to not pollute the mailing list with things
that might not lead anywhere. I hope you don't mind. We can rejoin the
list as soon (or if) there's something tangible.
I'm putting the reply to list, as this is something that could be
of interested to others too.
Please see attached (animated Gif) a quick first stab at a debugging
extension for VSCode . There are many things one might find irritating
about VSCode (I'm more a sublime guy) - but it has two things going in
it's favor: MIT-License and a Debugger-Extension API.
Nice.
This could be done in sth like Eclipse of course, but if I'd wanted
bloat... well, VScode is at least modern bloat (that's not necessarily
better, ofc). Unfortunately Sublime has no good way to implement
debugger views.
However, this is a simple use case for the Command Server implemented
inside an IDE with some simple source-mapping on top (slightly extended
Vasm LST-files to map PC->sourcefile/line; have to check what gcc
produces in that regard). >
While hacking away on this, some things did arise:
1. Debugger command line is blocking
This is in fact sth I always stumble upon while using the Hatari
debugger. Since there is no message queue while the debugger is active,
Hataris main window behaviour is pretty erratic (won't come to front,
You mean content isn't redrawn?
As interim solution, you could just continue for few instructions.
As a better solution, what if I would add some command to redraw
the window content?
Hatari marked as busy/not answering etc. YMMV depending on OS).
I'd like to move the debugger DebugUi_GetCommand into it's own thread.
This way the do/while in DebugUI() could handle basic SDL events and
rerender after executing a debugger command.
There could be some nasty things waiting here.
Debugger already prevents recursive calling that could happen
from parsing SDL input fully (including Hatari key shortcuts),
but none of it is made thread safe, there are static variables etc.
(A problem with the debugger is that it's grown slowly, which
means that it couldn't have been architected from the beginning.
As a result it's a bit crusty.)
Q: Were there any attempts to do this in Hatari before?
No.
IMHO better way than thread, could be just doing select() on relevant
file descriptors (see control.c on how to get SDL X socket),
but it's more OS/GUI specific than threading (for which SDL
provides some abstraction).
Q: Is it correct that only the command string read by fgets/readline
needs to be shared?
Shared with what?
Q: Anything obvious that I missed?
Q: Which Windows compiler is supported - e.g. is it OK to use pthread
and thus lock in on Mingw/GCC for windows targets? I tried a VC++
compile (project files generated via VC++ cmake target) a while ago and
IIRC it failed miserably.
I don't have any idea about Windows support. Nicolas is
the one doing Windows builds, but those are AFAIK
cross-compiled on Linux with Linux MinGW.
2. Getting data out of the debugger via text stream is pretty crude (a
regex-fest in my case)
Well at least the way I implemented it. Listening on stderr works, but
it gets unwieldy as soon as I'm requesting the guests whole memory, for
example (and I'd like to avoid hitting the disk as much as possible).
Python GUI for Hatari works like that too.
I tried to make nice debugger GUI on top of it, but concluded
that the text stream stuff is just too awkward & fragile for it.
Q: I currently have to attach and filter stderr for data needed (e.g.
TEXT address, PC etc.) since I don't get anything send back via control
socket. My fault? Or did I just not see the code that sends debugger
responses down the socket?
Currently about only thing that goes back to socket is window size.
Control socket isn't intended to be used over network, only locally,
so you have additional means of transferring data.
Instead of using socket, you can just open a fifo and tell Hatari to
put debugger output to that with the debugger "logfile" command.
Q: Is there any other way (more on the lines of a proper RPC with
structured results) to get call results?
No.
Would be nice (and way faster) to not have to regex registers and > memory dumps from a text stream.
Definitely.
However, the conclusion from the discussions on the list was that
good GUI should be in-process. It would be too awkward to try to
push all that stuff through socket, and other out-of-process methods
would be even less OS agnostic.
(For memory, better option for transferring it to another process
could be sharing that memory, but that's again very OS specific.)
Tentative agreement was that Qt would be the best GUI toolkit to
do in-process (debugger) GUI, as it's cross-platform. Nobody has
looked even into how one would integrate SDL mainloop with Qt though.
3. I'd like to see the current ray position
Let's say 1 is implemented. Having the option to see a little (red or
whatever is necessary to see it) dot at the current ray position would
be swell. I'll have to check if Hatari already has current line length
in cycles somewhere, but if it has, I could implement sth like that.
Nicolas might be interested also about that.
Q: Is there anything you can think of that would (technically) prevent
such an option ?
No.
Q: Does sth like Mr Nis E-Clock-sync via 60Hz lines affect the mapping
of the current cycle=>SDL surface pixel or can I rely on current line
count and line start Hatari provides?
Probably better to ask Nicolas about that.
4. I can't load symbols from PRG at an arbitrary address
Let's say I reload a PRG into Hatari (via load) over an already loaded
one, thus the basepage is not really related to the new binary any more.
I made a simple patch to Hatari to load symbols from an address by
stating it directly - like <symbols ../../build/debug/run.prg
"text-28">. Ofc this is a corner case, but it makes edit&continue so
much easier. I know that I could load a special symbol file (I even have
a converter from Vasms symbol files), but again I'd like to not hit the
disk too much.
Q: Did I miss a way to load symbols from a PRG w/o having a valid basepage?
I don't think so. I'd like to see your patch.
With 1. Hataris window would behave better in debugging workflows
(regardless if controlled or not). With 2. it would be easier for debug
servers to get register/memory dumps and even data for custom displays
(like rippers had BitD). 3. is just sth I really like in Steam SSE
debugger and would like to add to Hatari. Well and 4. is only to show
off Hatari to those perky WinUae users :) And it's very handy for
democoding.
I know that 2. is a bitch to solve (defining and maintaining all the
needed types etc.). Any experience with this on your end? Other ideas?
In the W windowing system I maintained [1]:
http://eerott.mbnet.fi/open.shtml#wws
All the network structs were maintained by hand, and IMHO doing it
manually isn't that hard.
However, nowadays people seem to be using mostly this for RPC:
https://developers.google.com/protocol-buffers/docs/overview
- Eero
[1] The debian source package doesn't build with current Debian
distros, because the Debian stuff it's using is (decade) too old.
I have fixes for that in my home git repo, but haven't had time
to finish all the changes I want for new release.