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

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

[Vince Weaver]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 757 bytes --]

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

Thanks for any help

Vince

[-- Attachment #2: Type: TEXT/PLAIN, Size: 549 bytes --]

! as -o mulscc.o mulscc.s ; ld -o mulscc mulscc.o

.equ SYSCALL_EXIT,1	

	.globl _start
_start:	
        wr  	%g0, %o3, %y
        sra 	%o5, 0x1f, %g2
        and  	%o3, %g2, %g2
        andcc	%g1, 0, %g1

	mulscc  %g1, %o5, %g1
	mulscc  %g1, %o5, %g1
	mulscc  %g1, %o5, %g1
	mulscc  %g1, %o5, %g1
		
	!================================
	! Exit
	!================================
exit:		
        mov	0,%o0			! exit value
        mov	SYSCALL_EXIT,%g1        ! put the exit syscall number in g1
        ta      0x10			! and exit

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 542 bytes --]

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

[Blue Swirl]

On 8/18/08, Vince Weaver <vince@csl.cornell.edu> 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.

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On 8/19/08, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 8/18/08, Vince Weaver <vince@csl.cornell.edu> 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.

[-- Attachment #2: fix_mulscc.diff --]
[-- Type: plain/text, Size: 1804 bytes --]

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

[rob1weld]

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
    

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.

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

[Anton Salikhmetov]

> 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.
>

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) (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



-----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.
>

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

[Thiemo Seufer]

rob1weld@aol.com wrote:
> 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) ...

FYI, I don't see this problem on a Linux/ppc host. It appears to be
limited to the x86 and x86_64 TCG implementation.


Thiemo

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

[Anton Salikhmetov]

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.
>>
>
>
>
>
>