Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 8:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
- save_state(dc, cpu_cond);
- gen_helper_wrpstate(cpu_tmp0);
- dc-npc = DYNAMIC_PC;
+
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Wed, Apr 27, 2011 at 12:35 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Wed, Apr 27, 2011 at 12:07 AM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real
issue may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch
and wrpr.
In theory there could be multiple issues including compiler
induced ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used
and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write
itself is OK.
The issue appears to be with save_state() call since adding
save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1,
cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Wed, Apr 27, 2011 at 7:29 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
- save_state(dc, cpu_cond);
- gen_helper_wrpstate(cpu_tmp0);
-
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 5:34 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Tue, Apr 26, 2011 at 12:29 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself is
OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
| static inline void gen_generic_branch(target_ulong npc1, target_ulong npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
Thanks!
I think the issue is more clear now, and loading to local temporary
works in this case.
Does not explain why unmodified qemu works with wrpr pstate not in delay slot.
Because the TCG branch is not generated in save_npc()?
I looked at my linux kernel builds and do not see any wrpr pstate in delay
slot.
Meaning you are not going to fix the bug? ;-)
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself is
OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Artyom
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 8:26 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
On Tue, Apr 26, 2011 at 5:34 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Tue, Apr 26, 2011 at 12:29 AM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
Thanks!
I think the issue is more clear now, and loading to local temporary
works in this case.
Does not explain why unmodified qemu works with wrpr pstate not in delay
slot.
Because the TCG branch is not generated in save_npc()?
I looked at my linux kernel builds and do not see any wrpr pstate in delay
slot.
Meaning you are not going to fix the bug? ;-)
More like I need to know where the bug is
because there is no issue running without wrpr in delay slot.
--
Kind regards,
Igor V. Kovalenko
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself is
OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
-save_state(dc, cpu_cond);
-gen_helper_wrpstate(cpu_tmp0);
-dc-npc = DYNAMIC_PC;
+{
+TCGv r_tmp = tcg_temp_local_new();
+
+
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
- save_state(dc, cpu_cond);
- gen_helper_wrpstate(cpu_tmp0);
- dc-npc = DYNAMIC_PC;
+
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
- save_state(dc, cpu_cond);
- gen_helper_wrpstate(cpu_tmp0);
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Wed, Apr 27, 2011 at 12:07 AM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko
atar4q...@gmail.com wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue
may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch
and wrpr.
In theory there could be multiple issues including compiler
induced ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used
and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself
is OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
| case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1,
cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
Hmm. This is not the only instruction using save_state() and cpu_tmp0.
At least ldd is another example.
| static inline void gen_generic_branch(target_ulong npc1, target_ulong
npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
You mean something like
case 6: // pstate
{
TCGv r_temp;
r_temp = tcg_temp_new();
tcg_gen_mov_tl(r_temp, cpu_tmp0);
save_state(dc, cpu_cond);
gen_helper_wrpstate(r_temp);
tcg_temp_free(r_temp);
dc-npc = DYNAMIC_PC;
}
break;
?
This fails with the same error message.
Close, but you need to use tcg_temp_local_new(). Does this work?
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 3c958b2..52fa2f1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3505,9 +3505,15 @@ static void disas_sparc_insn(DisasContext * dc)
tcg_gen_mov_tl(cpu_tbr, cpu_tmp0);
break;
case 6: // pstate
-
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Fri, Apr 22, 2011 at 06:14:06PM +0400, Igor Kovalenko wrote:
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko
igor.v.kovale...@gmail.com wrote:
Do you have public test case?
It is possible to code this delay slot write test but real issue may
be corruption elsewhere.
The test case is trivial: it's just the two instructions, branch and
wrpr.
In theory there could be multiple issues including compiler induced
ones.
I'd prefer to see some kind of reproducible testcase.
Ok, attached a 40 byte long test (the first 32 bytes are not used and
needed only because the bios entry point is 0x20).
$ git pull make sparc64-softmmu/qemu-system-sparc64 -bios
test-wrpr.bin -nographic
Already up-to-date.
make[1]: Nothing to be done for `all'.
/mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error
Aborted
The problem seems to be that wrpr is using a non-local
TCG tmp (cpu_tmp0).
Just tried the test case with write to %pil - seems like write itself is
OK.
The issue appears to be with save_state() call since adding save_state
to %pil case provokes the same tcg abort.
The problem is that cpu_tmp0, not being a local tmp, doesn't
need to be saved across helper calls. This results in the
TCG optimizer getting rid of it even though it's later used.
Look at the log and you'll see what I mean :-)
I'm not very comfortable with tcg yet. Would it be possible to teach
optimizer working with delay slots? Or do I look in the wrong place.
The problem is not on the TCG side, but on the target-sparc/translate.c
side:
|case 0x32: /* wrwim, V9 wrpr */
| {
| if (!supervisor(dc))
| goto priv_insn;
| tcg_gen_xor_tl(cpu_tmp0, cpu_src1, cpu_src2);
| #ifdef TARGET_SPARC64
Here cpu_tmp0 is loaded. cpu_tmp0 is a TCG temp, which means it is not
saved across TCG branches.
[...]
| case 6: // pstate
| save_state(dc, cpu_cond);
| gen_helper_wrpstate(cpu_tmp0);
| dc-npc = DYNAMIC_PC;
| break;
save_state() calls save_npc(), which in turns might call
gen_generic_branch():
| static inline void gen_generic_branch(target_ulong npc1, target_ulong npc2,
| TCGv r_cond)
| {
| int l1, l2;
|
| l1 = gen_new_label();
| l2 = gen_new_label();
|
| tcg_gen_brcondi_tl(TCG_COND_EQ, r_cond, 0, l1);
|
| tcg_gen_movi_tl(cpu_npc, npc1);
| tcg_gen_br(l2);
|
| gen_set_label(l1);
| tcg_gen_movi_tl(cpu_npc, npc2);
| gen_set_label(l2);
| }
And here is the TCG branch, which drop the TCG temp cpu_temp0.
The solution is either to rewrite gen_generic_branch() without TCG
branches, or to use a TCG temp local instead of a TCG temp.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull make sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted The problem seems to be that wrpr is using a non-local TCG tmp (cpu_tmp0). Just tried the test case with write to %pil - seems like write itself is OK. The issue appears to be with save_state() call since adding save_state to %pil case provokes the same tcg abort. The problem is that cpu_tmp0, not being a local tmp, doesn't need to be saved across helper calls. This results in the TCG optimizer getting rid of it even though it's later used. Look at the log and you'll see what I mean :-) I'm not very comfortable with tcg yet. Would it be possible to teach optimizer working with delay slots? Or do I look in the wrong place. -- Kind regards, Igor V. Kovalenko
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull make sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted HTH, Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ test-wrpr.bin Description: Binary data
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull make sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted The problem seems to be that wrpr is using a non-local TCG tmp (cpu_tmp0). Laurent
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull make sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted The problem seems to be that wrpr is using a non-local TCG tmp (cpu_tmp0). Just tried the test case with write to %pil - seems like write itself is OK. The issue appears to be with save_state() call since adding save_state to %pil case provokes the same tcg abort. -- Kind regards, Igor V. Kovalenko
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. The test case is trivial: it's just the two instructions, branch and wrpr. In theory there could be multiple issues including compiler induced ones. I'd prefer to see some kind of reproducible testcase. Ok, attached a 40 byte long test (the first 32 bytes are not used and needed only because the bios entry point is 0x20). $ git pull make sparc64-softmmu/qemu-system-sparc64 -bios test-wrpr.bin -nographic Already up-to-date. make[1]: Nothing to be done for `all'. /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error Aborted The problem seems to be that wrpr is using a non-local TCG tmp (cpu_tmp0). Just tried the test case with write to %pil - seems like write itself is OK. The issue appears to be with save_state() call since adding save_state to %pil case provokes the same tcg abort. The problem is that cpu_tmp0, not being a local tmp, doesn't need to be saved across helper calls. This results in the TCG optimizer getting rid of it even though it's later used. Look at the log and you'll see what I mean :-) Laurent
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Mon, Apr 11, 2011 at 9:53 PM, Artyom Tarasenko atar4q...@gmail.com wrote:
Can do it, but I'd like to understand first what we are looking for.
How does the main works in this case? Is it something like following?
translate {brz,pn ; wrpr} - optimize - execute -translate {retl ;
...} -optimize - execute.
The subject error is a tcg error, so it is happening in one of the two
translate/optimise phases drawn above, right?
So, why are we looking at the wrpr helper code?
Because you asked about alternate globals :)
Do you have public test case?
It is possible to code this delay slot write test but real issue may
be corruption elsewhere.
You assume ts-val_type gets corrupted? But then it must happen before
the wrpr helper call, or actually before the translation of {brz,pn ;
wrpr} block, no?
In theory there could be multiple issues including compiler induced ones.
I'd prefer to see some kind of reproducible testcase.
--
Kind regards,
Igor V. Kovalenko
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Mon, Apr 11, 2011 at 5:16 AM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Mon, Apr 11, 2011 at 12:00 AM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 end Does it mean the last block is processed correctly and the crash happens on the next instruction which doesn't make it to the log? The next instruction would be a 0x011fea30: retl Since it's a branch instruction I guess this would also be a tcg block boundary. -- Regards, Artyom Tarasenko solaris/sparc under qemu
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 end Does it mean the last block is processed correctly and the crash happens on the next instruction which doesn't make it to the log? The next instruction would be a 0x011fea30: retl Since
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On 10 April 2011 15:09, Artyom Tarasenko atar4q...@gmail.com wrote: Does it mean the last block is processed correctly and the crash happens on the next instruction which doesn't make it to the log? ...maybe tcg_abort() should do a qemu_log_flush()...? -- PMM
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 4:59 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 10 April 2011 15:09, Artyom Tarasenko atar4q...@gmail.com wrote: Does it mean the last block is processed correctly and the crash happens on the next instruction which doesn't make it to the log? ...maybe tcg_abort() should do a qemu_log_flush()...? Sounds reasonable, but in this particular case makes no difference. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 end Does it mean the last block is processed correctly and the crash happens on the next instruction which doesn't make it to
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 end Does it mean the last block is processed
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn $0x3,$0x68,$0x3 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c nopn $0x2,$0x2 nopn
Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
On Mon, Apr 11, 2011 at 12:00 AM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko igor.v.kovale...@gmail.com wrote: On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl blauwir...@gmail.com wrote: On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko atar4q...@gmail.com wrote: On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno aurel...@aurel32.net wrote: On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote: Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a tcg/tcg.c:1892: tcg fatal error error message. It looks like it can be a platform independent bug though, because when a '-singlestep' option IS present, qemu doesn't crash and seems to translate the code properly. (gdb) bt #0 0x0032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x0032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x0051933d in tcg_reg_alloc_call (s=value optimized out, def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at qemu/tcg/tcg.c:1892 #3 0x0051a557 in tcg_gen_code_common (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2099 #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 I\213n@H\213] 3\355I\211\256\220) at qemu/tcg/tcg.c:2142 #5 0x004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffd9b4) at qemu/translate-all.c:93 #6 0x004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x004d4029 in tb_find_slow (env1=value optimized out) at qemu/cpu-exec.c:167 #8 tb_find_fast (env1=value optimized out) at cpu-exec.c:194 #9 cpu_sparc_exec (env1=value optimized out) at qemu/cpu-exec.c:556 #10 0x00408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x0053c756 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at qemu/vl.c:1430 I inspected ts-val_type causing the abort() case and it turned out to be 0. The last lines of qemu.log (without -singlestep) IN: 0x011fe9f0: rdpr %pstate, %g1 0x011fe9f4: wrpr %g1, 2, %pstate -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -- IN: 0x011fe9f8: ldub [ %o0 ], %o1 0x011fe9fc: mov %o1, %o2 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=011fe9f8 npc=011fe9fc SP=0180ae41 pc: 011fe9f8 npc: 011fe9fc IN: 0x011fea00: rdpr %tick, %o3 0x011fea04: cmp %o1, %o2 0x011fea08: be %icc, 0x11fea00 0x011fea0c: ldub [ %o0 ], %o2 -- IN: 0x011fea10: brz,pn %o2, 0x11fe9f8 0x011fea14: mov %o2, %o4 -- IN: 0x011fea18: rdpr %tick, %o5 0x011fea1c: cmp %o2, %o4 0x011fea20: be %icc, 0x11fea18 0x011fea24: ldub [ %o0 ], %o4 -- IN: 0x011fea28: brz,pn %o4, 0x11fe9f4 0x011fea2c: wrpr %g0, %g1, %pstate EOF The crash is 100% reproducible and happens always on the same place, so it's probably a pure TCG issue, not related on getting the external/timer interrupts. Do you need any additional info? What would be interesting would be to get the corresponding TCG code from qemu.log (-d op,op_opt). OP: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0 movi_i64 cond,$0x1 set_label $0x0 0x11fea2c movi_i64 tmp7,$0x0 xor_i64 tmp0,tmp7,g1 movi_i64 pc,$0x11fea2c movi_i64 tmp8,$compute_psr call tmp8,$0x0,$0 movi_i64 tmp8,$0x0 brcond_i64 cond,tmp8,eq,$0x1 movi_i64 npc,$0x11fe9f4 br $0x2 set_label $0x1 movi_i64 npc,$0x11fea30 set_label $0x2 movi_i64 tmp8,$wrpstate call tmp8,$0x0,$0,tmp0 mov_i64 pc,npc movi_i64 tmp8,$0x4 add_i64 npc,npc,tmp8 exit_tb $0x0 OP after liveness analysis: 0x11fea28 ld_i64 tmp6,regwptr,$0x20 movi_i64 cond,$0x0 movi_i64 tmp8,$0x0 brcond_i64 tmp6,tmp8,ne,$0x0
