Re: [Qemu-devel] Re: SH4: Implement FD bit

[Lionel Landwerlin]

Le mardi 09 décembre 2008 à 19:36 +0300, Vladimir Prus a écrit :
> Aurelien Jarno wrote:
> 
> >> 
> >> SH4 manual say that if a floating point instruction is executed while
> >> FD bit in the status register is 1, an exception should be raised. QEMU
> >> presently does not do that, so the kernel does not initialize FP state
> >> for any thread, nor does it save/restore FP state. The most apparent
> >> consequence is that while recent gcc/libc expect double-precision mode
> >> to be set by kernel, they run in single-precision mode, and all FP code
> >> produces wrong values.
> >> 
> >> This patch fixes this. It also fixes a couple of places where PC was
> >> not updated before handling an exception, although both those places
> >> deal with invalid instruction and don't lead to any user-visible bugs.
> >> 
> >> - Volodya
> > 
> > Thanks, applied.
> 
> Thanks, but it looks like one bit of the patch somehow did not
> make it into SVN. Specifically, this:
> 
> @@ -504,6 +523,13 @@ static void _decode_opc(DisasContext * ctx)
>               }
>         }
>  
> +    /* The 0xfffd instruction is underfined, so we don't want to
> +       raise fpu disable exception on it.  */
> +    if (((ctx->opcode & 0xf000) == 0xf000)
> +       && (ctx->opcode != 0xfffd))      
> +      {
> +       CHECK_FPU_ENABLED
> +      }
> 
> Is present in my post, and is not present in:
> 
>         http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5937
> 
> Maybe some merge issue?
> 
> Thanks,
> Volodya
> 

Vladimir (Volodya ?),

you probably know better than me sh4 opcodes, but your patch is breaking my sh4 
user mode emulation.

$ ./sh4-linux-user/qemu-sh4 -strace -L /home/djdeath/taff/rootfs/ 
/middleware.dbg
1500 brk(0,0,0,1074264596,1074357772,0) = 0x00d98000
1500 uname(0x4007f6aa) = 0
1500 access("/etc/ld.so.preload",04) = -1 errno=2 (No such file or directory)
Unhandled trap: 0x800
pc=0x400977ea sr=0x00008001 pr=0x4008eae8 fpscr=0x00080000
spc=0x00000000 ssr=0x00000000 gbr=0x00000000 vbr=0x00000000
sgr=0x00000000 dbr=0x00000000 delayed_pc=0x400977e0 fpul=0x00000000
r0=0x000000e0 r1=0x00000000 r2=0x00008cf8 r3=0x4400302e
r4=0x4007f3f0 r5=0x00000000 r6=0x4007f57b r7=0x4008d200
r8=0x4007f3b8 r9=0x00b37cd0 r10=0x00000000 r11=0x4007f558
r12=0x400ae004 r13=0x00000000 r14=0x4007f3a4 r15=0x4007f3a4
r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000


According to you, should the FD bit be "up" by default in user mode emulation ?

By putting the FD bit "down" in cpu_sh4_reset(target-sh4/translate.c), I'm able 
to restore initial
behavior of user mode emulation (that means, qemu does not exits very early 
before libc initialization
(see the traces before)).

Maybe putting down the FD bit should be done in a user mode part only... I'm 
wondering...

Regards,

-- 
Lione Landwerlin                                         

O p e n W i d e                    14, rue Gaillon 75002 Paris