Any ARM Debuggers Ported to RO5 ?

It was easier in the days of RISC OS 2, you could redirect VDU to the serial device on one machine, and send the serial to the VDU on the other, it would then reproduce almost the entire desktop including window furniture, just lacking things such as sprites and draw files.

It’s a pity the same code couldn’t be used to fire at the Serial Port or screen.

Ralf seems to have a RPC and Pi so both should have a usable Serial Port.

It was easier in the days of RISC OS 2, you could redirect VDU to the serial device on one machine, and send the serial to the VDU on the other, it would then reproduce almost the entire desktop including window furniture, just lacking things such as sprites and draw files.

You can still do that to some extent…

Set Wimp$Font None
ToolSprites Resources:$.Resources.Wimp.Sprites

Clearing the Wimp font reverts to the system font, which is rendered through the VDU system. Using a toolsprites file that contains no actual tool sprites reverts to RISC OS 2 style rendering. You might also need to change the NVRAM setting that controls the tiled backgrounds of windows, but otherwise it should be very similar to the RISC OS 2 style redirection. Oh, except ColourTrans… hmm. You could probably sit something on ColourV which changed the operations into GCOL operations, but then things start to get more involved.

It’s all still RISC OS 2 under the hood :)

I remember how quickly a RO2 machine would start up – phone ring – beep Arc would be running.

Work on 32-bitting !ARM_Debug continues. My earlier graphics issues caused by RISC OS 5 not supporting the 4bpp modes have largely been overcome by manually changing all the screen colours and sprites in the ‘singlestepper’ module to use a 256 colour mode.

A lot of time and effort has gone into !ARM_Debug by the original authors, and the programme has a lot of functionality. However, I’m currently concentrating on getting the ‘singlestepper’ module working for modules in USR32 or SVC32 mode (as this is something that we cannot currently do on RISC OS 5). Once I’ve got the ‘singlestepper’ module working in USR and SVC modes working, Im planning on then using a renamed incarnation of the !ARM_Debug application (e.g. with the module SWIs renamed from xxxx to xxx1 etc), to be able to debug the remainder of the module ! Not tried this yet, but I reckon it should work ?? I could also modify the RISC PC version to prove that this theory works first…

For my testing I’m using the old (32-bitted) !BEdit application and the 32-bit ArmBE module (which seems to run mostly in USR32 mode). The ArmBE module is ideal because I can set a debugger break at the first LDR close to the start of the ArmBE module. And then trigger the debugger by simply dragging a BASIC file to !Bedit in the normal way. This brings up the ARM_Debug singlestepper debugger screen. Once there I can single-step through the instructions in the ArmBE module, and R0-R14, PC are updated in the normal way. I’ve also added the CPSR register to the debugger screen, so that you can see any ARM mode changes etc. At present the debugger is running correctly though the first 33 ArmBE instructions until SUBS R0,R0,#1, which correctly clears the ‘Z’ flag as R0 is decremented from 9 to 8. However, the BNE instruction does not jump back, and after this the PC is incremented correctly but none of the registers are loaded with the correct values.

Once the initial hard break has jumped from the ArmBE module into one of the !ARM_Debug instruction ‘sandboxes’, all ArmBE instruction processing continues to run in a sandbox in the ‘singlestepper’ module. On the RISC PC where the singlestepper module is working correctly you can set the ‘multi-step’ option after entering the ‘singlestepper’ module from a hard break. The multi-step option continues to run the ArmBE code in a sandbox and the usual ArmBE BBC BASIC screen appears after a few seconds. Clever stuff.

Furthermore, as the ‘singlestepper’ module is running the target module in a sandbox, it can check for likely aborts before running any instruction (its got a section that reads all the machines RAM and ROM etc using the standard OS calls – I guess to provide this functionality). I’ve seen a ‘singlestepper’ warning message appear saying that single-stepping through the next instruction will cause an ARM abort. The ‘singlestepper’ module also traps the RISC OS abort vectors, presumably for a similar purpose – although this was the first thing I turned off for 32-bitting as I wanted to get ‘new’ RISC OS crash dumps (e.g. Degugger$DumpOptions etc.). As an aside why didn’t RISC OS 2 produce proper crash dumps for data aborts ? But well done to Jeffrey and the RISC OS developers for adding this to RISC OS 5.

I started 32-bitting !ARM_Debug knowing that it was not going to be easy, but also unsure whether there would be an insurmountable obstacle that stopped this code working on modern ARM processors (to us) on RISC OS 5. Apart from the well known 32-bit PSR changes and Mode 31 no longer being supported as standard, it is just a matter of plodding on…

Once I get the ‘singlestepper’ module sandbox working well enough to run through all the ArmBE instruction to bring the BBC BASIC programme up on the screen, then I’ll update this thread.

Edit. Corrected some typos.

Good work – RO 5 can use all the colour modes if the hardware supports it.

I gather Pinebook Pro only manages 32bit colour.

It would be nice if Hardware that couldn’t support all the old colour modes couldn’t have a module to do so.

I finally got !ARM_Debug32 working last night, for modules in USR mode (i.e. ArmBE). I’d previously commented out a critical line of assembler, and this was stopping the debugger from working after there was any change in the sandbox’s status flags (i.e. b28-b31). It took me a week to find this self-inflicted ‘bug’. What I needed was a RISC OS 5 debugger that can work with any type of RO5 code :-).

Sandbox now runs code through in ‘multi-step’ – I eventually got a data abort for an ArmBE sandbox instruction. Not looked at this yet, but there were no data aborts in the ‘singlestepper’ module for a change…

I’ve not (yet?) uncovered any fundamental reason why !ARM_Debug won’t work on the RPi range of RISC OS 5 computers. My changes have been mostly MODE31 ‘stuff’ and moving the CPSR out of R15.

IMHO having independent PC and PSR registers actually makes the code for !ARM_Debug easier. I’ve probably taken out more instructions than I’ve added (MODE31 changes excepted).

Ralph

What I needed was a RISC OS 5 debugger that can work with any type of RO5 code

It may not meet your needs, but my Reporter provides SWIs which should work, and enable register values to be displayed (and more). I have certainly used it to debug assembler module code in SVC and USR modes (including Reporter itself!)

What I needed was a RISC OS 5 debugger that can work with any type of RO5 code :-).

I was just able to use !ARM_Debug to effectively step-though debug itself, by creating a second copy with modified names.

Initial trigger was done (as ever) by dragging a BASIC file to ArmBE. Which then fired up the first copy of !ARMDebug, which then first up the second copy – !ARM_Debug1.

Cool…

Ralph

ps. Reporter was a great help for debugging the WIMP front-end of !ARM_Debug – which is itself a complex programme including a lot of additional assembler.

Edit: Typos et al.

I’m playing around with a copy of the debugger that Ralph sent me a while back (sorry, only just gotten around to it!), and it is crashing (undefined instruction) when trying to go into the debugger proper.

The reason I’m asking here is that this is the offending code:

*Where
Address &2105FAF4 is at offset &00003540 in module 'BrkPointSet'
*ShowRegs
Register dump (stored at &20003110) is:
R0  = 200229D1 R1  = 2105FAEC R2  = 2105C628 R3  = 2105C5B4
R4  = 00000000 R5  = 0000352C R6  = 00000001 R7  = FFFFFFFF
R8  = 00000000 R9  = 00000000 R10 = 00000053 R11 = 30118758
R12 = 30118770 R13 = FA207F5C R14 = FC013A00 R15 = 2105FAF4
Mode SVC32 flags set: nzCvqjggggeAIFt        PSR = 201001D3
*MemoryI PC-20 +40
2105FAD4 : Ô.…å : E58C01D4 : STR     R0,[R12,#468]
2105FAD8 : x.…å : E58C0078 : STR     R0,[R12,#120]
2105FADC : D..ê : EA000C44 : B       &21062BF4
2105FAE0 : þ_-é : E92D5FFE : STMDB   R13!,{R1-R12,R14}
2105FAE4 : .. á : E1A0100F : MOV     R1,PC
2105FAE8 : ..Áã : E3C11003 : BIC     R1,R1,#3
2105FAEC : .ð)á : E129F001 : MSR     CPSR_cf,R1
2105FAF0 : .. á : E1A01000 : MOV     R1,R0
2105FAF4 < .. ã : E3A00010 : MOV     R0,#&10            ; =16
2105FAF8 : ÿ  ã : E3A020FF : MOV     R2,#&FF            ; ="ÿ"
2105FAFC : !..ï : EF020021 : SWI     XOS_ReadUnsigned
2105FB00 : .) c : 63A02902 : MOVVS   R2,#&8000
2105FB04 : ™.Rã : E3520F8D : CMP     R2,#&0234          ; =564
2105FB08 : P... : 0A000850 : BEQ     &21061C50
2105FB0C : . Âã : E3C22003 : BIC     R2,R2,#3
2105FB10 : .p á : E1A07002 : MOV     R7,R2
*

?

Why is MSR CPSR_cf,R1 failing? Is _cf some sort of deprecated combination these days? Or is it throwing its toys because R1 isn’t &xx0000xx (there are more bits set in the data than _cf requires)?

uncovered any fundamental reason why !ARM_Debug won’t work on the RPi range of RISC OS 5 computers.

What Pi are you using?

Most of the fixes that I have had to do to random stuff that broke was because the later ARMv7 in the Pi 2 is a lot stricter about what it’ll accept than the ARMv7 in the Beagle xM, and later models (Pi 2 revision 2 onwards) are ARMv8 which is likely stricter still and doesn’t support SWP any more (in case you use that).

By strict, I mean stuff like this will fail:
LDMIA R13!,{R0-R2,R13,PC}
or:
LDR R0,[R0]!
and other nonsensical instructions (that are often simple typos and/or memory lapses that turn up in handwritten code).

Are you emulating all of the instructions, or running them in a sanitised environment? If the latter, do you need to flush caches between writing instructions and executing them? IMBs? This sort of thing is more Jeffrey’s domain than mine. :)

I seem to recall there being a bug in !ARM_Debug, but I can’t seem to find my notes.

I vaguely remember it may have been related to it’s handling of LDM with PC in the list – possibly not working with the step debugger.

I’m playing around with a copy of the debugger that Ralph sent me a while back (sorry, only just gotten around to it!), and it is crashing (undefined instruction) when trying to go into the debugger proper.

What CPU is that on? I mentioned some odd behaviour with MSR depending on what CPU you’re using in this post.

What CPU is that on?

Pi 3B+ (Cortex-A53, ARMv8).

I’m playing around with a copy of the debugger that Ralph sent me a while back (sorry, only just gotten around to it!), and it is crashing (undefined instruction) when trying to go into the debugger proper.

The version of ARM_Debug I sent to you was not really working – I think that that was the first time I got the control screen. Lots of changes since then !

I’ll send you an updated version.

I would try changing that to a MSR CPSR_c as you haven’t changed the flags

What Pi are you using?

I am doing my conversion work using a Pi1, as it has a daughtercard with a very useful reset switch for lockups :-)

I’m also testing on my original RISC OS Pi2 and it also works OK. I’ll try it on a Pi3B+ or even a Pi4B later…

I seem to recall there being a bug in !ARM_Debug, but I can’t seem to find my notes. I vaguely remember it may have been related to it’s handling of LDM with PC in the list – possibly not working with the step debugger.

I think that !ARM_Debug is running each target instruction one-at-a-time, effectively in a sandbox. Same processor, same instruction but at a different PC memory address. ARM_Debug must be doing lots of clever things to addresses and offsets – i.e. more than just the ‘relocatable’ part of RMA for relocatable modules.

That said – I’d be very interested if you can find your notes…

Why is MSR CPSR_cf,R1 failing? Is _cf some sort of deprecated combination these days? Or is it throwing its toys because R1 isn’t &xx0000xx (there are more bits set in the data than _cf requires)?

I don’t understand exactly why the MRS is failing on the Rpi3B+ either (fails on my RPi3B+ too) ??

However, that MOV R1,PC looks wrong. This code is at the entry of the ‘*step’ command (which is a quick way of getting into the control screen). Changing this PC instruction to ‘MRS R1,CPSR’ makes the control screen load on the RPi3B+:-)

Ralph

with a very useful reset switch for lockups :-)

Standard issue for a RISC OS programmer, isn’t it? ;)

On Pi prior to the 3 (3B+?) you’d just hook a switch between RUN and the GND pin beside it.

As of the 3 (B+?), the two pin header is RUN and PEN (not GND) so you need to hook a switch between RUN and any convenient GND you find on the expansion header.
I just did this: https://heyrick.eu/blog/index.php?diary=20240322

ARM_Debug must be doing lots of clever things

Debuggers are akin to magic, and I’m especially impressed that it looks like you’ve been working through and commenting a disassembly of the original module.
I’d never have had either the patience or the attention span to do such a thing.

SVC32 mode (as this is something that we cannot currently do on RISC OS 5)

It’s a shame that nobody ever built a test harness that would patch a module and execute it in a semi-virtual environment in USR mode. There’s a hell of a lot of guff running in a privileged mode that really doesn’t need to.

Changing this PC instruction to ‘MRS R1,CPSR’ makes the control screen load on the RPi3B+:-)

Oh, it was loading an address instead of the flags.

Oh, I think I’ve got it. &2105FAEC sets bit 5 clear (%00100001 00000101 11111010 11101100).
Control state = %11101100 or Interrupt Disable, FIQ Disable, Thumb state, not 32 bit, processor mode “huh???”.
On the older Pi models that would have been the 26 bit (clear)/32 bit (set) toggle, which would effectively do nothing given there’s no 26 bit.
On 64 bit capable machines, that bit specifies 64 bit (clear) or 32 bit (set), and it was rejecting the instruction because clearing bit 5 is an invalid state (and there’s no thunking up to 64 bit from 32 bit); not to mention an undefined mode and Thumb. ;)

But, anyway, it was the wrong thing being written so no worries. Just good to work out what was happening.

Potentially the more worrying thing was why it didn’t fail on the older machines. Did they simply ignore the instruction?

Could a version of RO be done that had a flag set that requested USR mode instead of SVC.

I had a go of forcing USR mode using MSR.

Potentially the more worrying thing was why it didn’t fail on the older machines. Did they simply ignore the instruction?

That’s covered in the thread I linked above. The MSR would translate to one of several (now deprecated) instructions depending on the CPU and Debugger Module version. ARMv3/v4 it would be TSTP/TEQP/CMPP/CMNP and would probably do what it looks like it should be doing.

On ARMv5+ that sequence would have a random outcome as its doing more than just switch to USR32, which its doing vicariously anyway.

As noted in the linked thread, on ARMv3 onward in 32bit mode the preferred method is MRS / alter just the bits intended / MSR.

For full ARM support, you’d need to detect If the CPU is in 26/32bit mode and use the appropriate method to set R1 initially. As-is for 26bit and MRS for 32bit.

It not supposed to work – but has anyone here used MSR to change to 64bit and back!

It would be nice if there was a download page for the latest version of Arm_Debug ‘Rick’?

It not supposed to work

Correction – it does not work. By design.

but has anyone here used MSR to change to 64bit and back!

Such a processor would be considered defective.
It isn’t 1987 any more. Whether something is 32 bit or 64 bit is under the strict control of the hypervisor, and absolutely not a user mode program bumping itself to kernel level and fiddling flags. Any mainstream modern OS that allowed such a thing would get CVE’d out of existence.

Note, incidentally, that the two are effectively entirely different processors, so there needs to be a clear division between the two. One can’t run code written for the other.

a download page for the latest version of Arm_Debug

That’s up to Ralph, it’s not my project.
If it was mine, I would not release it publicly yet, only to those who understand it’s a work in progress and may blow up in exciting ways. ;)

Be patient…