From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtJym-00005l-11 for qemu-devel@nongnu.org; Fri, 24 Oct 2008 06:33:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtJyl-00005R-5R for qemu-devel@nongnu.org; Fri, 24 Oct 2008 06:33:15 -0400 Received: from [199.232.76.173] (port=49724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtJyl-00005H-0a for qemu-devel@nongnu.org; Fri, 24 Oct 2008 06:33:15 -0400 Received: from rv-out-0708.google.com ([209.85.198.248]:43444) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtJyb-00063u-Nh for qemu-devel@nongnu.org; Fri, 24 Oct 2008 06:33:06 -0400 Received: by rv-out-0708.google.com with SMTP id f25so728712rvb.22 for ; Fri, 24 Oct 2008 03:33:04 -0700 (PDT) Message-ID: <4df4ef0c0810240333w62eb9dc0obb058137f111be26@mail.gmail.com> Date: Fri, 24 Oct 2008 16:33:04 +0600 From: "Anton Salikhmetov" Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86 In-Reply-To: <8CB001D82773607-9B4-176D@WEBMAIL-MY02.sysops.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4df4ef0c0810180516u2a1e2eccr2de61663b460edb2@mail.gmail.com> <8CB001D82773607-9B4-176D@WEBMAIL-MY02.sysops.aol.com> 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 Cc: rob1weld@aol.com 2008/10/19 : > Thanks for that, Anton. > > > I did a diff of those two versions: > # svn diff -r 5252:5253 svn://svn.sv.gnu.org/qemu/trunk > > and indeed "target-mips/translate.c" was the only file changed. I am not as > familiar with the Qemu code as I would > like to be; nothing struck me as 'obvious' (other than that there were more > than a few changes between those two revisions) ... > > > I checked out the newest revision and saw no update to > "target-mips/translate.c" so I made a diff of the version > that you suggested was the last working version against the current revision > (5499). > > # svn diff -r 5252:5499 > svn://svn.sv.gnu.org/qemu/trunk/target-mips/translate.c > tmt.patch > # patch -R --verbose trunk/target-mips/translate.c < tmt.patch > > That un-did 16 hunks. It is unfortunate to undo that much work but I wanted > to see if it would compile. > > It does! > > > I installed the new compilation (with the 'old' target-mips/translate.c > revision and the rest of the code 'new' ) and booted. > > # cat /proc/version > Linux version 2.6.26-1-4kc-malta (Debian 2.6.26-7) (waldi@debian.org) (gcc > version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 Wed Oct 1 14:08:21 > UTC 2008 > > > I figure if I can run Linux 2.6.26-7 then it is "working". > > Now to go back and re-hunk (one or more at a time) until the offending hunk > is discovered. That is the 'correct' way to > properly fix the code. In the mean time one can simply use the old 5252 > version of that one file with the 5499 version of Qemu. > > > Thanks, Anton, > > Rob I have just faced the same problem "tcg fatal error" when installing many Debian packages inside of "qemu-system-mips" built from the 5252 revision. But now it appears extremely rarely, not every time "qemu-system-mips" starts (that behavior was for the revisions after 5253 inclusive). So I presume this bug to be of stress nature. Hope it is going to be fixed someday. Anton > > > > -----Original Message----- > From: Anton Salikhmetov > To: qemu-devel@nongnu.org > Cc: rob1weld@aol.com > Sent: Sat, 18 Oct 2008 5:16 am > Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86 > >> From: >> Date: 2008/10/13 >> Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86 >> To: qemu-devel@nongnu.org >> >> >> When I run the current trunk (revision 5478) with >> "/usr/local/bin/qemu-system-mips -cpu 24Kc -M malta ..." I get a >> similar error (calls tcg_abort() ) to the one described by Vince: >> >> >> /build/qemu/trunk/tcg/tcg.c:1484: tcg fatal error >> Aborted >> >> >> If I use exactly the same command but use the "Lenny Debian >> GNU/Linux's repository version" of qemu-system-mips (version 0.9.1-6) >> the error does not occur. Thus, this error is occurring on the MIPS >> platform (host x86) as well as the SPARC. >> >> Rob > > I'm having the same error when using qemu-system-mips (-M malta). By > bisection, the revisions 5252 and 5253 were found (5252 is working > fine, while 5253 is not). All the revisions after 5253 have the same > problem with "tcg fatal error" for me. By the way, the only file > target-mips/translate.c is changing while updating the source code > from 5252 to 5253. Hope it helps to close the bug. > > Anton > >> >> On 8/19/08, Blue Swirl wrote: >>> >>> On 8/18/08, Vince Weaver wrote: >>> > Hello >>> > >>> > I'm continuing on my quest to get the SPEC2000 benchmarks running >> >> under >>> >>> > sparc32-linux-user (so far 8 out of 48 work). >>> > >>> > Many of the benchmarks die early on with the following error: >>> > >>> > /fusion/research4/vince/qemu/svn/tcg/tcg.c:1455: tcg fatal >> >> error >>> >>> > >>> > This error is caused when tcg_reg_alloc_mov() is called but >> >> ts->val_type >>> >>> > is equal to 0 (which is TEMP_VAL_DEAD). So maybe the optimizer is >>> > optimizing away something that it shouldn't? >>> > >>> > This happens in a block with multiple calls to the SPARC "mulscc" >>> > instruction which is a complicated instruction, so maybe this is >> >> finding an >>> >>> > obscure corner case. >>> > >>> > I've attached a very small sample program that exhibits the bug >> >> when run >>> >>> > with ./sparc32-linux-user/qemu-sparc32plus >>> >>> >>> Okay, I can finally reproduce this. Strangely it does not occur if -d >>> flag is used and "op" is one of the log items. I have to check if >>> older reports where I could not reproduce the bug were suffering > > from >>> >>> the same problem. >>> >>> But I haven't found any fix yet. >> >> I have isolated the problem to andi op. The attached patch makes the >> bug go away by disabling the offending andi, but it's of course not a >> real fix. Why andi fails with op flag enabled, I have no idea. >> > > > > >