[Rpcemu] Error-returning bug in EmuFS

Jan Rinze janrinze at gmail.com
Fri Jun 12 18:22:13 PDT 2009


Hi Theo,

I have noticed similar behaviour when copying large trees to a sparkfs  
archive. Almost seemingly at random files appear to be 'in use' this  
is with rpcemu spoon 0.8.4 To me this is 'new' behaviour. Not sure  
what causes it..

Jan Rinze.

Op 13 jun 2009 om 03:01 heeft Theo Markettos <rpcemu at markettos.org.uk>  
het volgende geschreven:\

> 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)
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu at riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu



More information about the Rpcemu mailing list