From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQp6V-00062Q-9K for qemu-devel@nongnu.org; Wed, 06 Aug 2008 15:55:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQp6U-00061W-GD for qemu-devel@nongnu.org; Wed, 06 Aug 2008 15:55:26 -0400 Received: from [199.232.76.173] (port=41384 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQp6U-000615-4X for qemu-devel@nongnu.org; Wed, 06 Aug 2008 15:55:26 -0400 Received: from yw-out-1718.google.com ([74.125.46.156]:28732) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQp6T-0008QO-Ev for qemu-devel@nongnu.org; Wed, 06 Aug 2008 15:55:25 -0400 Received: by yw-out-1718.google.com with SMTP id 6so50883ywa.82 for ; Wed, 06 Aug 2008 12:55:23 -0700 (PDT) Message-ID: Date: Wed, 6 Aug 2008 22:55:22 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] one more SPARC issue In-Reply-To: <20080806152607.J61277@stanley.csl.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080728225136.C26546@stanley.csl.cornell.edu> <20080805161615.S57426@stanley.csl.cornell.edu> <761ea48b0808051336o120c3e9j286d9523a693f98f@mail.gmail.com> <20080805223132.C58183@stanley.csl.cornell.edu> <20080806152607.J61277@stanley.csl.cornell.edu> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 8/6/08, Vince Weaver 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: jseward@bzip.org. 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.