Re: [Qemu-devel] one more SPARC issue

[Blue Swirl]

On 8/6/08, Vince Weaver <address@hidden> wrote:
>
>  I found one last SPARC issue, this time with the falign() function.
>
>  This one was a pain to track down because gdb won't let you show the %gsr
> register, or any of the floating point registers above %f32.
>
>  The falign code does this:
>
>      tmp = (*((uint64_t *)&DT0)) << ((env->gsr & 7) * 8);
>      tmp |= (*((uint64_t *)&DT1)) >> (64 - (env->gsr & 7) * 8);
>
>  But in the case where %gsr is zero, the second case turns into a
>  shift left of 64, which on many architectures turns into a no-op (rather
> than clearning the result to zero).
>
>  So in this case, the output of the falign was rs1 *or'd* with rs2, rather
> than just plain rs1.
>
>  I've included a patch below that fixes things for me, and I've also
> attached a test case that shows the bug.
>
>  With this, I can finally run the spec 2006 bzip2 benchmark to completion
> under sparc32plus-linux-user

Thanks, applied.

There are still other bugs:
dd if=/dev/zero bs=3334 count=1 | ./qemu-sparc64 -L . -d in_asm,op_opt
../bzip2.sparc64 | bzcat | hexdump -C
1+0 records in
1+0 records out
3334 bytes (3.3 kB) copied, 3.4e-05 seconds, 98.1 MB/s

bzip2.sparc64: Caught a SIGSEGV or SIGBUS whilst compressing.

   Possible causes are (most likely first):
   (1) This computer has unreliable memory or cache hardware
       (a surprisingly common problem; try a different machine.)
   (2) A bug in the compiler used to create this executable
       (unlikely, if you didn't compile bzip2 yourself.)
   (3) A real bug in bzip2 -- I hope this should never be the case.
   The user's manual, Section 4.3, has more info on (1) and (2).

   If you suspect this is a bug in bzip2, or are unsure about (1)
   or (2), feel free to report it to me at: address@hidden
   Section 4.3 of the user's manual describes the info a useful
   bug report should have.  If the manual is available on your
   system, please try and read it before mailing me.  If you don't
   have the manual or can't be bothered to read it, mail me anyway.

        Input file = (stdin), output file = (stdout)
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000d00  00 00 00 00 00 00                                 |......|
00000d06

With bs=3333 it works as expected.