Experimental Debugger Support for Arculator

[monibius]

Hi Folks,
TL;DR: I'm looking to gauge interest from the community for full GDB debugger support on the host machine for applications running in an emulator. I've been working on a proof of concept (a mod for Arculator itself) whereby you can cross-compile your C/C++ application using GCCSDK using your IDE of choice on your host machine and in that IDE (or the GDB command line) you can set breakpoints, inspect variables, step through code and all the other things you'd expect from a modern IDE. Taking this over the finish line will require quite a but more investment so please let me know if this might be of interest, or indeed if you already have a good/better solution it would be useful to hear what that is.

Detail:-
Maximising developer productivity would probably help to get more things written/done for RISC OS. I've been considering my own productivity and I'd definitely like a more optimal way to debug my software.

GDB is supported by many IDEs. GDB supports connecting to a remote system to debug software (this could be another PC or a microcontroller). This is usually done behind the scenes using The GDB Remote Serial Protocol (RSP) which supports UART or TCP Sockets. The idea has been to have Arculator implement the RSP protocol using sockets, with a fair bit of extra translation coded in to deal with an application running in RISC OS, in virtual/mapped memory, running in an emulator and translating all that through to what GDB expects on the host machine. GDB will then talk from the host machine to the emulator (Arculator) and in turn interact with the RISC OS application being debugged. Note even though the interaction between GDB and the emulator would happen behind the scenes using sockets, it's expected that GDB and the emulator would all be running on the same physical host machine.
Because the emulator implements this protocol and logic, we can add pretend 'hardware support' of sorts to aid debugging, allowing full visibility of what is going on from the host machine, without unwanted side effects within the emulation environment and also without having to change the way in which programs are built (other than to build with debug symbols).

There is quite a lot more to this, I can add more detail later. I also have vague thoughts on extending this to allow debugging both applications and RISC OS itself - maybe even stepping between applications and the OS in the debugger . I also haven't considered RPCEmu but something should be similarly possible there too.

It's possible there are already really good ways of achieving high productivity with alternate debugging methods and this is all a bit pointless. Or it's possible this may actually be really useful. There is a lot more work still to do, so I wanted to checkpoint here before continuing to see if further effort makes sense. Thanks for your thoughts!

[kieranhj]

Hello!

This sounds like a fantastic project. I would definitely be interested in using GDB connected to Arculator as a debugging solution for Archimedes app development. I have certainly missed the in-built debugging that comes with the 8-bit emulators like b-em and beebjit. Having a debugger that lives entirely ‘outside’ of the hardware with the ability to fully inspect all machine state is incredibly powerful. To date I have been making do with !DDT within RISCOS of the emulated machine, but this is slow and difficult to use for demos / games that are not windowed. I should say that my particular use case would be for pure ARM assembler code, not C/C++ built with GCC, but the ability to step the assembly and inspect registers & memory etc. would still be tremendously valuable.

Extending the Arculator source is relatively easy. I made a virtual Podule that similarly connects to a PC application via sockets running on the same host machine. In this case it used the Podule memory mapped area to communicate with a track sequencing tool, albeit the protocol is significantly simpler than GDB RSP!

Happy to be a tester for this if helpful.

[monibius]

Thanks for the feedback!

I should say that my particular use case would be for pure ARM assembler code, not C/C++ built with GCC, but the ability to step the assembly and inspect registers & memory etc. would still be tremendously valuable.

This will work. I'm not sure if you would also want to place breakpoints etc on your .asm files and step through that way. It may be possible to get the assembler to output debugging symbols to allow the mapping of the PC address back to the source file line, etc. It may even be possible to mouse over register names in the source file and see the values that way - similar to a modern IDE setup. I'd love to also unlock some of this functionality as assembler is so popular.

[sirbod]

Having a step debugger outside of RISC OS would be very useful.

I don't personally use C/C++ under RISC OS 3, but stepping through machine code with breakpoints and tracing would help diagnose low-level issues. For the wider community I feel RPCEmu would be a more useful platform as RISC OS 5 is where the majority of development now takes place.

[monibius]

but stepping through machine code with breakpoints and tracing would help diagnose low-level issues

Makes sense, that's two people looking for these capabilities for debugging in assembler. I'll test these scenarios too.

For the wider community I feel RPCEmu would be a more useful platform as RISC OS 5 is where the majority of development now takes place.

Great - I should imagine once I have this working as intended under Arculator, I'll do a RPCEmu version too (I totally agree this would likely see wider usage). The techniques will be similar to the Arculator version, but the method of hooking in to the internals of the emulator will of course be different.

[IanJeffray]

Actually even just full decoded trace (disassembled instruction + regset) would be super useful to see,

[dpsharp]

This would be very cool! Strong +1 for assembly debugging and implementing it on RPCemu though for my purposes I could make use of it on Arculator too. I'd ideally look to use it from a Mac host but could use Windows too.

I've had a little hobby project and being using Paul Thompson's interactive debugger (https://heyrick.eu/assembler/debugger.html) heavily on RPCemu. It's surprisingly powerful and easy to use but there's a couple of glitches (it doesn't recover back to original screen palette/mode though I partly hacked in the code from desktop Hacker to achieve this, and it sometimes chokes on interrupts from sound playing but turning off sound in the game i'm debugging seems to avoid it) so something as you describe would be even better.