PrivateEye 3.20 ready for testing

> Make supervisor stack inaccessible to user mode

That’ll be it then.

Make supervisor stack inaccessible to user mode

That’ll be it then.

It is indeed, verified with ROM builds here. However is simply unwinding this the “right” thing to do. See the reasoning given here

However is simply unwinding this the “right” thing to do.

It’s a positive change… but DragAnObject will need fixing along with it.

Browse crashes in the same way, ta Mr Sprow.

but DragAnObject will need fixing along with it.

I completely agree. Keep the SVC stack locked away, and fiddle with DragAnObject so it isn’t doing naughty things…

For a quick 32-bit fix, in DragAnObject’s renderuserfunc move the LDM {R0-R3} (the called rendering function’s args) to before the SWI XOS_LeaveOS, which will preserve those regs. A 26-bit fix could just be a separate conditionally assembled branch added to this for a soft-loaded module. [Edit: the LDR PC,[R12,#4] to call the function is also problematic – see below.]

Bit of an assumption that the user’s R13 is a FD stack pointer too, which it will be 99.9% of the time, but need not be. For the paranoid, user R14 could be saved in the SVC stack with STM/LDM ^ (no wb, so adjust sp_svc before/after).

For a quick 32-bit fix, in DragAnObject’s renderuserfunc move the LDM {R0-R3} […]

(As an aside:) This is such delightful Chinese for me!
(Just to be sure, I don’t speak Chinese.)

Here we go:

*RMFaster DragAnObject

(NB addresses are for my ARMX6, yours will differ)

*Modules

136 2049A8F4 00000000  DragAnObject

Original, faulty code, is:

*memoryi (module_base)+318+50
2049AC0C : .. ã : E3A00006 : MOV     R0,#6
2049AC10 : .. ã : E3A01000 : MOV     R1,#0
2049AC14 : .  ã : E3A02010 : MOV     R2,#&10            ; =16
2049AC18 : X..ï : EF020058 : SWI     XOS_ReadSysInfo
2049AC1C : .% c : 63A02507 : MOVVS   R2,#&01C00000
2049AC20 : .*‚b : 62822A02 : ADDVS   R2,R2,#&2000
2049AC24 : .@Bâ : E242400C : SUB     R4,R2,#&0C         ; =12
2049AC28 : .Pό : E59C5008 : LDR     R5,[R12,#8]
2049AC2C : ..-é : E92D1800 : STMDB   R13!,{R11,R12}
2049AC30 : ..ӏ : E8940C00 : LDMIA   R4,{R10,R11}
2049AC34 : |..ï : EF02007C : SWI     XOS_LeaveOS
2049AC38 : .ð?c : 633FF000 : TEQVSP  PC,#0
2049AC3C : ..•è : E895000F : LDMIA   R5,{R0-R3}
2049AC40 : .à-å : E52DE004 : STR     R14,[R13,#-4]!
2049AC44 : .à á : E1A0E00F : MOV     R14,PC
2049AC48 : .ðœå : E59CF004 : LDR     PC,[R12,#4]
2049AC4C : .àä : E49DE004 : LDR     R14,[R13],#4
2049AC50 : ...ï : EF020016 : SWI     XOS_EnterOS
2049AC54 : ..½è : E8BD1800 : LDMIA   R13!,{R11,R12}
2049AC58 : ÿ‡½è : E8BD87FF : LDMIA   R13!,{R0-R10,PC}

a) Swap these two instructions:

SWI     XOS_LeaveOS

LDMIA   R5,{R0-R3}

b) Replace the 26-bit-only

TEQVSP  PC,#0

LDR     R12,[R12,#4]

c) Replace the

LDR     PC,[R12,#4]

MOV     PC,R12

Giving ===>

*memoryi (module_base)+318+50
2049AC0C : .. ã : E3A00006 : MOV     R0,#6
2049AC10 : .. ã : E3A01000 : MOV     R1,#0
2049AC14 : .  ã : E3A02010 : MOV     R2,#&10            ; =16
2049AC18 : X..ï : EF020058 : SWI     XOS_ReadSysInfo
2049AC1C : .% c : 63A02507 : MOVVS   R2,#&01C00000
2049AC20 : .*‚b : 62822A02 : ADDVS   R2,R2,#&2000
2049AC24 : .@Bâ : E242400C : SUB     R4,R2,#&0C         ; =12
2049AC28 : .Pό : E59C5008 : LDR     R5,[R12,#8]
2049AC2C : ..-é : E92D1800 : STMDB   R13!,{R11,R12}
2049AC30 : ..ӏ : E8940C00 : LDMIA   R4,{R10,R11}
2049AC34 : ..•è : E895000F : LDMIA   R5,{R0-R3}
2049AC38 : .Àœå : E59CC004 : LDR     R12,[R12,#4]
2049AC3C : |..ï : EF02007C : SWI     XOS_LeaveOS
2049AC40 : .à-å : E52DE004 : STR     R14,[R13,#-4]!
2049AC44 : .à á : E1A0E00F : MOV     R14,PC
2049AC48 : .ð á : E1A0F00C : MOV     PC,R12
2049AC4C : .àä : E49DE004 : LDR     R14,[R13],#4
2049AC50 : ...ï : EF020016 : SWI     XOS_EnterOS
2049AC54 : ..½è : E8BD1800 : LDMIA   R13!,{R11,R12}
2049AC58 : ÿ‡½è : E8BD87FF : LDMIA   R13!,{R0-R10,PC}

Maybe someone nice will knock up a BASIC program to apply this?!

The patch above has been applied to the source, Titanium and RPi ROMs built, and the Effects Drag and Drop is fine.

Woohoo!

For anyone interested, the offending source is here:

https://gitlab.riscosopen.org/RiscOS/Sources/Desktop/DragAnObj/-/blob/master/s/DragAnObj#L389

at least I think that corresponds with what Stuart has posted above. If I had my RISC OS machine up and running, I’d probably give a merge request a bash. In theory, it could be done with the WebIDE, but I don’t think ROOL would look too kindly on something unassembled/untested!

That’s the one, Richard.

It’d make sense and save code to just preserve/restore R0-R12,LR/PC in all the render functions.

Err… what should mediocre souls like me exactly do to get this sorted?

Err… what should mediocre souls like me exactly do to get this sorted

If you are not in a position to be able to roll-your-own ROM, I’m afraid it’s wait until a fix is rolled into the nightly build, Paul.

[Edit: Or use the DragAnObject patcher in the post below.]

Here’s a patcher writ in BASIC to be going on with: (deleted) Note that it is specific to DragAnObject 0.09, which is the one included in the troublesome RISC OS 5 ROM builds. Don’t run on RISC OS 4 etc.

Stuart, when I run your patch, I get the following error: Offset 340 contains &E895000F but EF02007C expected at line 300
Doing a *memoryi shows that nothing has changed. What should I do now?

Sounds like the one in your system has assembled to be two words shorter than the one in my ARMX6, Paul.

The patcher checks that all the words are as expected before modifying anything.

Try just subtracting 8 from L1% thru L4%

[or, as an exercise for the reader, loop L1% from &300 to &400 stopping when you first encounter L1_OLD% (the SWI XOS_LeaveOS, which only occurs once in that module). Then set L2% thru L4% to be L1%8, L1%4 and L1%+20 (not 16) respectively. NB these are DECIMAL offsets.]

Try just subtracting 8 from L1% thru L4%

Is that &8? So, should I type L1% = &332 for example? When I do, I get another error.

EDIT: Forget that, I just can’t calculate – not even in decimal.

EDIT2: Well, even with the right subtractions, I get an error. Besides that, I’ve no idea what I’m doing.

L1% = &340-8 etc. :-) You have BASIC on your side, even if the bits are glowing dim.

There are four locations to patch. Each must already contain the correct instruction, as in L1_OLD% etc. before they are patchable. Note that it doesn’t check to see if it’s patched already, just that those words are in the expected order. If you have already patched it, the patcher will fail.

Oh dear!!

Stuart’s first patch runs here on a Titanium with out error.

*FX0
RISC OS 5.29 (30 Oct 2022)
*RMFaster DragAnObject
*ADFS::Titan4.$._Temp.PEye-patch.PatchDragAnObject009
*

A cheeky *save added to the end of the patch BASIC verifies that the patch has happened.

There is just one tiny little snag, PrivateEye’s Effects still explodes. A source code patched ROM is just fine.

Similartly on the RPi400, the patch applies but to no effect.

There is just one tiny little snag, PrivateEye’s Effects still explodes.

That’s because Stuart is a cretin (and why I invited someone else to do this…).

Thanks. Please try the updated updated one:

https://croftnuisk.co.uk/coltsoft-downloads/other/PatchDragAnObject009-revC.zip

revC works, tried on both the RPi400 and Titanium.

Thanks for testing :-)

Stuart is a cretin

You’re a rebaked french bread product?
Or am I thinking something else?

I always thought “cretin” was from Latin, and meant “a Christian”…

Is fench bread made in Fance?