[Rpcemu] Error-returning bug in EmuFS

Theo Markettos rpcemu at markettos.org.uk
Fri Jun 12 18:01:00 PDT 2009


I've been trying to build the ROOL sources on RPCEmu, having them mounted as
a Samba share on the Linux host from another Linux machine. I've run into a
bug in EmuFS (svn167, RO4.39, dynarec).

Very simply demonstrated:
> F%=OPENOUT("Test")
> P.F%
     251
> F2%=OPENOUT("Test")
> P.F2%
     34662412
> P.~F2%
     210E80C

Address &210E80C contains the equivalent of:

.&0210E80C
DCD 0001BEC2  
DCS "This file is already open"
DCB 0

So, evidently, the V flag isn't being set on return from the EmuFS module.

But I tried, in BASIC in User mode, the code snippet in EmuFS that sets the
V flag and that's fine:

error_generate:
        teq     r0, r0                          @ Set Z, so pc as operand 1
                                                  and 2 will be different in 26 bit user mode
        teq     pc, pc
        orrnes  pc, lr, #VBIT                   @ Return with V set, caller
                                                  flags preserved (26 bit mode)
        msr     cpsr_flg, #VBIT                 @ Set V current flags
                                                  preserved
        mov     pc, lr                          @ Return error function with
                                                  V set, caller flags corrupted (32 bit mode)

(MSR is &E328F201 as BASIC can't assemble it.  The code in EmuFS is
bit-for-bit the same as the code that BASIC assembled)

And that's the last the EmuFS module does before returning to FileSwitch...
so I don't see how it could fail to be passed on.  Since the MessageTrans
lookup has happened the V flag has obviously been passed through from the
host code.

I tried this in assembler:
ADR R1,test
MOV R0,#&8C
SWI "XOS_Find"
MOV PC,R14
.test
DCS "Test"
DCB 0

And lookend at the status before calling MOV PC,R14 (with a breakpoint): R0
points to the error message but the V flag isn't set.  So it's nothing to do
with BASIC being odd.

Unless there's some problem with the V bit setting in supervisor mode I'm a
bit stuck.  Ideas?

Theo

(I don't think this is actually what's been annoying the ROOL build though -
looks like we're failing to write to existing files at all, even ones that
have been opened for the first time.  Only seems to happen on the Samba
share, even though Linux can write just fine, as can RISC OS on occasion)



More information about the Rpcemu mailing list