From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNtMc-00015s-Md for qemu-devel@nongnu.org; Tue, 29 Jul 2008 13:51:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNtMY-00014V-RO for qemu-devel@nongnu.org; Tue, 29 Jul 2008 13:51:57 -0400 Received: from [199.232.76.173] (port=35507 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNtMY-00014Q-HL for qemu-devel@nongnu.org; Tue, 29 Jul 2008 13:51:54 -0400 Received: from wf-out-1314.google.com ([209.85.200.174]:25354) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNtMX-0002Gj-FP for qemu-devel@nongnu.org; Tue, 29 Jul 2008 13:51:54 -0400 Received: by wf-out-1314.google.com with SMTP id 27so6608787wfd.4 for ; Tue, 29 Jul 2008 10:51:48 -0700 (PDT) Message-ID: Date: Tue, 29 Jul 2008 20:51:48 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] x86 tcg problem In-Reply-To: <20080728225136.C26546@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> 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 7/29/08, Vince Weaver wrote: > Hello > > I've spent a day now trying to figure out why bzip2 compress/decompress > doesn't work when using sparc32plus-linux-user on x86. > > I've tracked the problem to the Zero flag being improperly set (attached is > a small exe/src that reproduces the problem.. it reports "Greater" > on real hardware, "Less Than" on qemu current). > > The issue seems to be a misordering of an x86 sub instruction. I tried to > track this down in the tcg code but I quickly got lost. > > The code does this for a compare (on sparc the compare turns into a > subtract with result as the [ignores] zero reg): > > mov_i32 cc_src_0,g4_0 ; > mov_i32 cc_src_1,g4_1 ; load g4 (0xaae60) > mov_i32 cc_src2_0,g3_0 ; > mov_i32 cc_src2_1,g3_1 ; load g3 (0) > sub2_i32 > cc_dst_0,cc_dst_1,cc_src2_0,cc_src2_1,cc_src_0,cc_src_1 > ; result = 0xaafe0-0 > movi_i32 psr,$0x0 ; clear psr > mov_i32 tmp42,cc_dst_0 ; get cc_dst_0 > movi_i32 tmp43,$0x0 ; > movi_i32 tmp44,$0x0 ; > movi_i32 tmp45,$0x0 ; zero extends > brcond2_i32 tmp42,tmp43,tmp44,tmp45,$0x1,$0x0 ; if not > zero, skip > movi_i32 tmp19,$0x400000 ; else set zero flag > > > > which converts into x86: > 0xb80da04d: sub %ecx,%eax ; %ecx = g4-g3 > 0xb80da04f: sbb %ebx,%edx > 0xb80da051: mov %eax,0x6c(%ebp) ; saving g3, not the result (ecx)! > 0xb80da054: mov %edx,0x70(%ebp) ; > 0xb80da057: xor %edx,%edx > 0xb80da059: xor %ecx,%ecx ; clearing our result for use as > psr > ; result is lost! > ; the later test for zero is done > ; against g3 instead, which > ; sets the zero flag when it > ... ; shouldn't > 0xb80da06f: test %eax,%eax > 0xb80da071: jne 0xb80da091 ; skip if not zero > .. > 0xb80da07f: mov 0x8c(%ebp),%eax ; load psr > 0xb80da085: or $0x400000,%eax ; set zero flag > > > So unless there's some weird AT&T/intel ordering thing that is confusing me > (please let me know if I am missing something), TCG is getting confused > about which argument of the subtract is the result. I'm not sure how to fix > this though... Now I found the problem, (1 << 31) could be negative on 64 bit variable. I'm testing a fix. It looks like this also solves some of the Sparc64 boot problems, like Aurora 2.0 which complained about CRC error.