Better debugging

Which makes me think if it would be easy to do such things on base of the RPCemu?

Hard task.

Chris did port RPCEmu under RISC OS, but:
- Without keyboard support: the macOS patches could perhaps help here.
- Slow: will need a JIT engine.

And of course, you’ll need to add debugging tools on RPCEmu :)

IMHO, it will be simpler to adapt RISC OS 5 for a crude RISC OS hypervisor using paravirtualisation.

Somebody suggested that a debugger based on an emulator would be a good approach. Which makes me think if it would be easy to do such things on base of the RPCemu?

In the last few days I’ve done something along these lines. Not so much writing a debugger as bodging a few lines of code into RPCEmu to record a rolling log, of instructions I’m interested in, into a big array and then spit that out to the log file if an abort happens, along with a register dump and the instruction and values that caused the abort.

It’s helped me track down a new bug in my Paint code that was causing an abort and then crashing RISC OS when it was simply trying to run a CLG.

It occurred to me you could probably achieve a similar thing running RPCEmu under Linux or Windows by actually running the emulator inside an IDE and setting conditional breakpoints in the arm.c source (although you might struggle to keep a history of the code execution that way).

In my code changes I was just logging details of LDMFD, STMFD and branches to trace function calls, as well as SWIs. It’s useful for what I needed but it’s worth noting that it makes the emulator run extremely slowly. It’s not of a good enough quality to release although if anyone desperately needs this functionality I could probably email the code. There’s very little to it.

It’s useful for what I needed but it’s worth noting that it makes the emulator run extremely slowly.

Perhaps, rather than putting the output into an array you could send the lines of text as SysLog messages.

Typically SysLog on Linux will do all the log rollover and gzip archiving and then final age out for you.
Never looked at the same on Windows but it’s probably available.

Typically SysLog on Linux will do all the log rollover and gzip archiving and then final age out for you.

That could be handy but I’d need to stop the logging quite quickly after a crash happens, otherwise it might rollover afterwards and lose the information leading up to the crash. At the moment I write the recent history to RPCEmu’s log file every time an exception of type ABORT happens (Yeah, don’t do it on all types of exception as those happen hundreds of times in RISC OS!).

If I wanted to I might be able to speed it up slightly by logging the instructions as hex values into the array and only translating them to text if and when it needs to write to the log file; at the moment they’re stored as strings. I also don’t know how much of the slowdown is just due to switching off dynamic recompilation (which obviously isn’t really suitable for debugging like this).

That could be handy but I’d need to stop the logging quite quickly after a crash happens, otherwise it might rollover afterwards and lose the information leading up to the crash.

SysLog in RO is slightly misleading in that the rollover has a relatively limited number of previous files because it doesn’t compress. On Linux the SysLog implementation keeps the current and 1 or two uncompressed previous then all others in the cycle are GZipped. Text file compression is quite good.
I was running a FreeRADIUS server with logs that rolled over weekly and kept 52 weeks (arbitrary value) of previous files. That was logging RADIUS authentication events on a 5000 device network.
The tools exist to examine the GZipped files as though they were standard.