[Rpcemu] Error-returning bug in EmuFS
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:
Address &210E80C contains the equivalent of:
DCS "This file is already open"
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:
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
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
I tried this in assembler:
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?
(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