Remote debugging of code running in UAE

[copse]

I've been considering options for my disassembler, and one is to hook it up to UAE and debug something running within it. I thought I would write up my research notes here. Screenshots are linked from the Github page referred below, so may stop working.

Extending UAE for external debugging

The first stop is this FS-UAE issue. The author works on changes that allow debugging the running Amiga in Visual Studio Code. This is continued by another person and is for FS-UAE.



However there is another project for WinUAE that is not as far as I can tell usable with VSCode, but the FS-UAE project author would merge that support in if this were merged into WinUAE in place of his FS-UAE patches. It is also included as a Windows build in a VSCode extension.

Neither of these were merged, I don't think Toni was interested and he probably prioritises things he will use himself.

External debugging support with GDB

Another developer chimed in and mentioned they had their own Python script that could launch an executable in a minimally modified UAE and breakpoint it on main. It appears to wrap FS-UAE debugging commands with a gdbstub compatible server, and gdb communicates with his external Python server.



I'm not a big fan of having to modify and compile projects and keep a fork merged with a parent branch myself, it's a huge pain point. Anyway, this user has a now archived Github project that has some interesting references, python-amidev. It seems to send commands to the UAE debugger, presumably through the named pipe, but I am not so sure. One of the files, sadfe.py, seems to communicate with a different debugger, SAD. I initially assumed this was some Amiga executable developed by this developer, but it is not the case it's in the.. kickstart?.

I got two relevant matches using the Google search, and it seems to be a simple amiga debugger built into Workbench/Kickstart 3.0 or something. One of these, on amiga.org, suggests it is invoked by "loadwb -debug" and points us to the Autodoc for SAD (but does not link to it). A bit of mucking around gives us this link to the autodoc sections.

Anyway, SAD must supplement the UAE debugger commands presumably as a secondary debugging tool. The developer seems to maintain their external and minimal UAE debugging changes in this repository.

[copse]

Okay, received a response from Krystian, the developer of the GDB approach. He found the SAD approach to be a dead end, so gave up on it. He points me to his new repository, which has a pretty good readme with screenshots. The source level debugging is quite nice, and comes from the GDB protocol I guess.

https://github.com/cahirwpz/demoscene

He takes an approach vaguely similar to what I guess I might try. They have some effect source code as a rom, they include it with their bootloader and presumably invoke the executable's code on reboot.

I would instead do something with ColdCapture and library patching as a bootstrap to breakpointing on the main function of the relevant executable in DOS. This Xine seems to give me a good refresher and starting points on how to go about this. Wandel disassembled a bootblock that does a RTC_COLDSTART romtag, given a late enough Kickstart RTC_AFTERDOS might be an option. Here's an ominous reference by Toni that AFTERDOS is broken.

[copse]

Here's someone in the FS-UAE thread talking about using fake Autoconfig boards to install handling for remote debugging of UAE.

Here's a thread from EAB on the subject of how Autoconfig works.

Looking at the WinUAE options, it does not appear possible to create custom expansions. So that makes this a dead end as far as I can tell.

[copse]

The Bartman WinUAE embedded gdb server. This is available as a published VSCode extension apparently.

The prb28 FS-UAE embedded gdb server

The latest version of the cahirwpz external Python GDB server that wraps a "lightly modifed" FS-UAE. Debugger commands are sent via stdin to FS-UAE, although I suspect it could be modified to use the named pipe and send IPC commands

None of the above appear to support enumeration of processes at the debugger level, which might be useful. But I think that's a task for later.

Ghidra seems to be usable with a debugger, but really any work invested in setting up some kind of gdb server with a UAE version for my own disassembler is groundwork that should apply to Ghidra.

[copse]

Video of the Ghidra amiga hunk loader author [ Show youtube player ] disassembling Powerpacker (I repeat that as the link get's youtube playerafied) in both IDA and Ghidra. He shows how to do A4 offsets in each, and among other things uses Bartman's VSCode environment to debug powerpacker in WinUAE and to attach to the process in IDA. Is in Russian, so he is pretty much mumbling to himself and it is not understandable.

[Thomas Richter]

Quite simple. Get COP, from aminet, attach a serial terminal program such as "Minicom" on linux at either 9600 8N1 or 115200 8N1, then go "COP serial" on the shell. Press "ESC" anytime on the serial link, and you are in the debugger. Or start a CLI program with "COP CLIDebug program", or a workbench program.

There is a tutorial here (in German)

https://www.a1k.org/forum/index.php?threads/73115/

Make sure you read the manual, comes with the debugger.


SAD is dead. 3.1.4 comes with ROMWack again, but COP is certainly more powerful.

[copse]

Downloaded Ghidra version 9.2.2 and the ghidra_hunk_ldr plugin version 9.2. The plugin does not work out of the box, as the plugin version has to match the Ghidra version, so I needed to extract it, update it, rezip it up and then install the extension. This is done by selecting the zip file, and that puts the zip file contents (including the bundled fd data files in "C:\Users\<username>\.ghidra\.ghidra_9.2.2_PUBLIC\Extensions"). I had some errors with the plugin where it did not install the data files for some reason perhaps related to the version problems, and had to track this down with ProcessMonitor.

The plugin does do library call analysis, but it seems a little wonky. What it actually does is add labels for each library in some allocated memory space, then maps these to the call offsets. I am not sure what the repercussions of this are with respect to recompilation. It also sets them all to exec and you have to go through and switch between the known symbols for calls (with the R key). Additionally, it only adds symbols for libraries you specify at analysis time when you first import your executable.

It's a step up from Resource. It'd be better to do the library calls another way I suspect, and it provides decompiled C code, which is a lot more readable than the assembly. I am not sure what the goal of disassembling something in this is, maybe just to understand the code. Would the C code be close to being compiled? Is the resulting assembler compilable in anything? No idea at this point.

[copse]

Originally Posted by Thomas Richter

Quite simple. Get COP, from aminet, attach a serial terminal program such as "Minicom" on linux at either 9600 8N1 or 115200 8N1, then go "COP serial" on the shell. Press "ESC" anytime on the serial link, and you are in the debugger. Or start a CLI program with "COP CLIDebug program", or a workbench program.

There is a tutorial here (in German)

https://www.a1k.org/forum/index.php?threads/73115/

Make sure you read the manual, comes with the debugger.


SAD is dead. 3.1.4 comes with ROMWack again, but COP is certainly more powerful.

Hi Thomas, that link is not accessible. I also have no interest in debugging anything unless it is integrated into the disassembler I will use, so not sure that is really applicable in any case. The GDB protocol seems to be the gold standard for this, in the emulation scene.

[copse]

Example of decompilation versus disassembly.

[copse]

I've now spent some time in Ghidra, and there's a lot to like that if I recall correctly are likely based on IDA. The fact you can see strings as placeholder comments beside the assembler disassembly. The ability to follow back references which was a serious lacking from Resource, and see what calls something as comments around it.

The library call resolution that comes with the ghidra_ldr_plugin is a hack to make up for the fact that the equates are really poor as far as I can tell. It creates segments that somehow get linked to library calls, and for every library you select (you have to manually select them at point of analysis) it creates the symbols in a custom segment and it matches every single one of them to every single library call. This isn't so much analysis as just faking availability of equates, and all the calls default to exec library and you have to go through and switch the symbols.

I am told that you can't have negative equates at this time, so it is probably not possible to do library calls correctly currently.

There are two additional features that I like, that I don't really want to bother doing in my own disassembler so it pushes me to using Ghidra. The automatic detection and formalisation of "function parameters" from stack offsets. And the decompilation, which is very valuable for seeing structure of the code you are looking at.

[Int42]

How do I remote debug with fs-uae per tcp and a terminal program like putty? I started fs-uae with the option --serial_port=tcp://127.0.0.1:1234 and then I connected via Putty to that socket. This is working, but which command I must type in to get debug information?

I know there are VSCode extension with remote debugging features, but I dont wont to use microsoft tools for that.