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

["Anton Salikhmetov" <salikhmetov@gmail.com>]

2008/10/19  <rob1weld@aol.com>:
> 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 <salikhmetov@gmail.com>
> 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:  <rob1weld@aol.com>
>> 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 <blauwirbel@xxxxxxxxx> wrote:
>>>
>>> On 8/18/08, Vince Weaver <vince@xxxxxxxxxxxxxxx> 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.
>>
>
>
>
>
>