Re: [Qemu-devel] tcg problem running SPARC program on x86

[rob1weld]

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) (address@hidden) 
(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



-----Original Message-----
From: Anton Salikhmetov <address@hidden>
To: address@hidden
Cc: address@hidden
Sent: Sat, 18 Oct 2008 5:16 am
Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86

> From:  <address@hidden>
> Date: 2008/10/13
> Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86
> To: address@hidden
>
>
> 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 <address@hidden> wrote:
> > On 8/18/08, Vince Weaver <address@hidden> 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.