* [Qemu-devel] tcg/tcg.c:1892: tcg fatal error @ 2011-04-10 12:29 Artyom Tarasenko 2011-04-10 13:24 ` Aurelien Jarno 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 12:29 UTC (permalink / raw) To: qemu-devel, Blue Swirl 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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at qemu/translate-all.c:93 #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 #11 cpu_exec_all () at qemu/cpus.c:1102 #12 0x000000000053c756 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: 0x00000000011fe9f0: rdpr %pstate, %g1 0x00000000011fe9f4: wrpr %g1, 2, %pstate -------------- IN: 0x00000000011fe9f8: ldub [ %o0 ], %o1 0x00000000011fe9fc: mov %o1, %o2 0x00000000011fea00: rdpr %tick, %o3 0x00000000011fea04: cmp %o1, %o2 0x00000000011fea08: be %icc, 0x11fea00 0x00000000011fea0c: ldub [ %o0 ], %o2 Search PC... Search PC... Search PC... Search PC... Search PC... Search PC... -------------- IN: 0x00000000011fe9f8: ldub [ %o0 ], %o1 0x00000000011fe9fc: mov %o1, %o2 0x00000000011fea00: rdpr %tick, %o3 0x00000000011fea04: cmp %o1, %o2 0x00000000011fea08: be %icc, 0x11fea00 0x00000000011fea0c: ldub [ %o0 ], %o2 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 npc=00000000011fe9fc SP=000000000180ae41 pc: 00000000011fe9f8 npc: 00000000011fe9fc IN: 0x00000000011fea00: rdpr %tick, %o3 0x00000000011fea04: cmp %o1, %o2 0x00000000011fea08: be %icc, 0x11fea00 0x00000000011fea0c: ldub [ %o0 ], %o2 -------------- IN: 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 0x00000000011fea14: mov %o2, %o4 -------------- IN: 0x00000000011fea18: rdpr %tick, %o5 0x00000000011fea1c: cmp %o2, %o4 0x00000000011fea20: be %icc, 0x11fea18 0x00000000011fea24: ldub [ %o0 ], %o4 -------------- IN: 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 0x00000000011fea2c: 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? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 12:29 [Qemu-devel] tcg/tcg.c:1892: tcg fatal error Artyom Tarasenko @ 2011-04-10 13:24 ` Aurelien Jarno 2011-04-10 14:09 ` Artyom Tarasenko 0 siblings, 1 reply; 32+ messages in thread From: Aurelien Jarno @ 2011-04-10 13:24 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, qemu-devel 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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 > #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 > #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, > tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at > qemu/translate-all.c:93 > #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, > cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 > #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 > #11 cpu_exec_all () at qemu/cpus.c:1102 > #12 0x000000000053c756 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: > 0x00000000011fe9f0: rdpr %pstate, %g1 > 0x00000000011fe9f4: wrpr %g1, 2, %pstate > -------------- > IN: > 0x00000000011fe9f8: ldub [ %o0 ], %o1 > 0x00000000011fe9fc: mov %o1, %o2 > 0x00000000011fea00: rdpr %tick, %o3 > 0x00000000011fea04: cmp %o1, %o2 > 0x00000000011fea08: be %icc, 0x11fea00 > 0x00000000011fea0c: ldub [ %o0 ], %o2 > > Search PC... > Search PC... > Search PC... > Search PC... > Search PC... > Search PC... > -------------- > IN: > 0x00000000011fe9f8: ldub [ %o0 ], %o1 > 0x00000000011fe9fc: mov %o1, %o2 > 0x00000000011fea00: rdpr %tick, %o3 > 0x00000000011fea04: cmp %o1, %o2 > 0x00000000011fea08: be %icc, 0x11fea00 > 0x00000000011fea0c: ldub [ %o0 ], %o2 > > 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 > npc=00000000011fe9fc SP=000000000180ae41 > pc: 00000000011fe9f8 npc: 00000000011fe9fc > > IN: > 0x00000000011fea00: rdpr %tick, %o3 > 0x00000000011fea04: cmp %o1, %o2 > 0x00000000011fea08: be %icc, 0x11fea00 > 0x00000000011fea0c: ldub [ %o0 ], %o2 > -------------- > IN: > 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 > 0x00000000011fea14: mov %o2, %o4 > -------------- > IN: > 0x00000000011fea18: rdpr %tick, %o5 > 0x00000000011fea1c: cmp %o2, %o4 > 0x00000000011fea20: be %icc, 0x11fea18 > 0x00000000011fea24: ldub [ %o0 ], %o4 > -------------- > IN: > 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 > 0x00000000011fea2c: 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 aurelien@aurel32.net http://www.aurel32.net ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 13:24 ` Aurelien Jarno @ 2011-04-10 14:09 ` Artyom Tarasenko 2011-04-10 14:44 ` Blue Swirl 2011-04-10 14:59 ` Peter Maydell 0 siblings, 2 replies; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 14:09 UTC (permalink / raw) To: Aurelien Jarno; +Cc: Blue Swirl, qemu-devel On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >> qemu/translate-all.c:93 >> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >> #11 cpu_exec_all () at qemu/cpus.c:1102 >> #12 0x000000000053c756 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: >> 0x00000000011fe9f0: rdpr %pstate, %g1 >> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >> -------------- >> IN: >> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >> 0x00000000011fe9fc: mov %o1, %o2 >> 0x00000000011fea00: rdpr %tick, %o3 >> 0x00000000011fea04: cmp %o1, %o2 >> 0x00000000011fea08: be %icc, 0x11fea00 >> 0x00000000011fea0c: ldub [ %o0 ], %o2 >> >> Search PC... >> Search PC... >> Search PC... >> Search PC... >> Search PC... >> Search PC... >> -------------- >> IN: >> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >> 0x00000000011fe9fc: mov %o1, %o2 >> 0x00000000011fea00: rdpr %tick, %o3 >> 0x00000000011fea04: cmp %o1, %o2 >> 0x00000000011fea08: be %icc, 0x11fea00 >> 0x00000000011fea0c: ldub [ %o0 ], %o2 >> >> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >> npc=00000000011fe9fc SP=000000000180ae41 >> pc: 00000000011fe9f8 npc: 00000000011fe9fc >> >> IN: >> 0x00000000011fea00: rdpr %tick, %o3 >> 0x00000000011fea04: cmp %o1, %o2 >> 0x00000000011fea08: be %icc, 0x11fea00 >> 0x00000000011fea0c: ldub [ %o0 ], %o2 >> -------------- >> IN: >> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >> 0x00000000011fea14: mov %o2, %o4 >> -------------- >> IN: >> 0x00000000011fea18: rdpr %tick, %o5 >> 0x00000000011fea1c: cmp %o2, %o4 >> 0x00000000011fea20: be %icc, 0x11fea18 >> 0x00000000011fea24: ldub [ %o0 ], %o4 >> -------------- >> IN: >> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >> 0x00000000011fea2c: 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 0x00000000011fea30: retl Since it's a branch instruction I guess this would also be a tcg block boundary. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 14:09 ` Artyom Tarasenko @ 2011-04-10 14:44 ` Blue Swirl 2011-04-10 17:48 ` Artyom Tarasenko 2011-04-10 14:59 ` Peter Maydell 1 sibling, 1 reply; 32+ messages in thread From: Blue Swirl @ 2011-04-10 14:44 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>> qemu/translate-all.c:93 >>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>> #12 0x000000000053c756 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: >>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>> -------------- >>> IN: >>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>> 0x00000000011fe9fc: mov %o1, %o2 >>> 0x00000000011fea00: rdpr %tick, %o3 >>> 0x00000000011fea04: cmp %o1, %o2 >>> 0x00000000011fea08: be %icc, 0x11fea00 >>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>> >>> Search PC... >>> Search PC... >>> Search PC... >>> Search PC... >>> Search PC... >>> Search PC... >>> -------------- >>> IN: >>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>> 0x00000000011fe9fc: mov %o1, %o2 >>> 0x00000000011fea00: rdpr %tick, %o3 >>> 0x00000000011fea04: cmp %o1, %o2 >>> 0x00000000011fea08: be %icc, 0x11fea00 >>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>> >>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>> npc=00000000011fe9fc SP=000000000180ae41 >>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>> >>> IN: >>> 0x00000000011fea00: rdpr %tick, %o3 >>> 0x00000000011fea04: cmp %o1, %o2 >>> 0x00000000011fea08: be %icc, 0x11fea00 >>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>> -------------- >>> IN: >>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>> 0x00000000011fea14: mov %o2, %o4 >>> -------------- >>> IN: >>> 0x00000000011fea18: rdpr %tick, %o5 >>> 0x00000000011fea1c: cmp %o2, %o4 >>> 0x00000000011fea20: be %icc, 0x11fea18 >>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>> -------------- >>> IN: >>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>> 0x00000000011fea2c: 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 > > 0x00000000011fea30: retl > > Since it's a branch instruction I guess this would also be a tcg block boundary. Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 14:44 ` Blue Swirl @ 2011-04-10 17:48 ` Artyom Tarasenko 2011-04-10 17:57 ` Blue Swirl 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 17:48 UTC (permalink / raw) To: Blue Swirl; +Cc: peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: > On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>> qemu/translate-all.c:93 >>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>> #12 0x000000000053c756 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: >>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>> -------------- >>>> IN: >>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>> 0x00000000011fe9fc: mov %o1, %o2 >>>> 0x00000000011fea00: rdpr %tick, %o3 >>>> 0x00000000011fea04: cmp %o1, %o2 >>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>> >>>> Search PC... >>>> Search PC... >>>> Search PC... >>>> Search PC... >>>> Search PC... >>>> Search PC... >>>> -------------- >>>> IN: >>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>> 0x00000000011fe9fc: mov %o1, %o2 >>>> 0x00000000011fea00: rdpr %tick, %o3 >>>> 0x00000000011fea04: cmp %o1, %o2 >>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>> >>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>> npc=00000000011fe9fc SP=000000000180ae41 >>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>> >>>> IN: >>>> 0x00000000011fea00: rdpr %tick, %o3 >>>> 0x00000000011fea04: cmp %o1, %o2 >>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>> -------------- >>>> IN: >>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>> 0x00000000011fea14: mov %o2, %o4 >>>> -------------- >>>> IN: >>>> 0x00000000011fea18: rdpr %tick, %o5 >>>> 0x00000000011fea1c: cmp %o2, %o4 >>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>> -------------- >>>> IN: >>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>> 0x00000000011fea2c: 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 >> >> 0x00000000011fea30: retl >> >> Since it's a branch instruction I guess this would also be a tcg block boundary. > > Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' > (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. Any idea why? retl is not a rare instruction... -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 17:48 ` Artyom Tarasenko @ 2011-04-10 17:57 ` Blue Swirl 2011-04-10 18:35 ` Artyom Tarasenko 0 siblings, 1 reply; 32+ messages in thread From: Blue Swirl @ 2011-04-10 17:57 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>> qemu/translate-all.c:93 >>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>> #12 0x000000000053c756 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: >>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>> -------------- >>>>> IN: >>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>> >>>>> Search PC... >>>>> Search PC... >>>>> Search PC... >>>>> Search PC... >>>>> Search PC... >>>>> Search PC... >>>>> -------------- >>>>> IN: >>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>> >>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>> >>>>> IN: >>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>> -------------- >>>>> IN: >>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>> 0x00000000011fea14: mov %o2, %o4 >>>>> -------------- >>>>> IN: >>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>> -------------- >>>>> IN: >>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>> 0x00000000011fea2c: 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 >>> >>> 0x00000000011fea30: retl >>> >>> Since it's a branch instruction I guess this would also be a tcg block boundary. >> >> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. > > Any idea why? retl is not a rare instruction... Sorry, calls are generated for helpers, so it's not 'jmpl' but the call to wrpstate helper. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 17:57 ` Blue Swirl @ 2011-04-10 18:35 ` Artyom Tarasenko 2011-04-10 18:52 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 18:35 UTC (permalink / raw) To: Blue Swirl; +Cc: peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: > On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>> qemu/translate-all.c:93 >>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>> #12 0x000000000053c756 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: >>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>> -------------- >>>>>> IN: >>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>> >>>>>> Search PC... >>>>>> Search PC... >>>>>> Search PC... >>>>>> Search PC... >>>>>> Search PC... >>>>>> Search PC... >>>>>> -------------- >>>>>> IN: >>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>> >>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>> >>>>>> IN: >>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>> -------------- >>>>>> IN: >>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>> -------------- >>>>>> IN: >>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>> -------------- >>>>>> IN: >>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>> 0x00000000011fea2c: 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 >>>> >>>> 0x00000000011fea30: retl >>>> >>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>> >>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >> >> Any idea why? retl is not a rare instruction... > > Sorry, calls are generated for helpers, so it's not 'jmpl' but the > call to wrpstate helper. And why it doesn't happen in a singlestep mode? I tried to comment out cpu_check_irqs(env); in the helper_wrpstate but it made no difference. The only suspicious thing left is register bank switching. Is it safe to switch register banks in the helper function? Shouldn't we end the translation block before? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 18:35 ` Artyom Tarasenko @ 2011-04-10 18:52 ` Igor Kovalenko 2011-04-10 19:37 ` Artyom Tarasenko 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-10 18:52 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>>> qemu/translate-all.c:93 >>>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>>> #12 0x000000000053c756 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: >>>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>>> -------------- >>>>>>> IN: >>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>> >>>>>>> Search PC... >>>>>>> Search PC... >>>>>>> Search PC... >>>>>>> Search PC... >>>>>>> Search PC... >>>>>>> Search PC... >>>>>>> -------------- >>>>>>> IN: >>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>> >>>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>>> >>>>>>> IN: >>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>> -------------- >>>>>>> IN: >>>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>>> -------------- >>>>>>> IN: >>>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>>> -------------- >>>>>>> IN: >>>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>>> 0x00000000011fea2c: 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 >>>>> >>>>> 0x00000000011fea30: retl >>>>> >>>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>>> >>>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >>> >>> Any idea why? retl is not a rare instruction... >> >> Sorry, calls are generated for helpers, so it's not 'jmpl' but the >> call to wrpstate helper. > > And why it doesn't happen in a singlestep mode? > I tried to comment out > cpu_check_irqs(env); > in the helper_wrpstate but it made no difference. The only suspicious > thing left is register bank switching. Is it safe to switch register > banks in the helper function? Shouldn't we end the translation block > before? > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ > > Not sure if I have seen write to pstate in delay slot, but switching globals with PS_AG appears to be safe. Do you know which bits are changed in the pstate? -- Kind regards, Igor V. Kovalenko ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 18:52 ` Igor Kovalenko @ 2011-04-10 19:37 ` Artyom Tarasenko [not found] ` <BANLkTik2NChYi8hADjCSbjdZeyP_oo8_Qg@mail.gmail.com> 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 19:37 UTC (permalink / raw) To: Igor Kovalenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>>>> qemu/translate-all.c:93 >>>>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>>>> #12 0x000000000053c756 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: >>>>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>>>> -------------- >>>>>>>> IN: >>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>> >>>>>>>> Search PC... >>>>>>>> Search PC... >>>>>>>> Search PC... >>>>>>>> Search PC... >>>>>>>> Search PC... >>>>>>>> Search PC... >>>>>>>> -------------- >>>>>>>> IN: >>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>> >>>>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>>>> >>>>>>>> IN: >>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>> -------------- >>>>>>>> IN: >>>>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>>>> -------------- >>>>>>>> IN: >>>>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>>>> -------------- >>>>>>>> IN: >>>>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>>>> 0x00000000011fea2c: 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 >>>>>> >>>>>> 0x00000000011fea30: retl >>>>>> >>>>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>>>> >>>>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>>>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >>>> >>>> Any idea why? retl is not a rare instruction... >>> >>> Sorry, calls are generated for helpers, so it's not 'jmpl' but the >>> call to wrpstate helper. >> >> And why it doesn't happen in a singlestep mode? >> I tried to comment out >> cpu_check_irqs(env); >> in the helper_wrpstate but it made no difference. The only suspicious >> thing left is register bank switching. Is it safe to switch register >> banks in the helper function? Shouldn't we end the translation block >> before? > > Not sure if I have seen write to pstate in delay slot, but switching > globals with PS_AG appears to be safe. > Do you know which bits are changed in the pstate? Hard to say. With a breakpoint set qemu doesn't crash. The breakpoint shows the change from 0x14->0x16. So the only difference is that interrupts are getting enabled. No register bank change. (And now also no cpu_check_irqs(env) call, because I commented it out.) But given there was a Data Access MMU Miss, I would expect there must have beeb a PS_MG switch. Also the breakpoint makes tcg to cut the translation block before the wrpr: IN: 0x00000000011fea18: rdpr %tick, %o5 0x00000000011fea1c: cmp %o2, %o4 0x00000000011fea20: be %icc, 0x11fea18 0x00000000011fea24: ldub [ %o0 ], %o4 -------------- IN: 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 -------------- IN: 0x00000000011fea2c: wrpr %g0, %g1, %pstate -------------- IN: 0x00000000011fea30: retl -------------- IN: 0x00000000011fea30: retl 0x00000000011fea34: sub %o5, %o3, %o0 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <BANLkTik2NChYi8hADjCSbjdZeyP_oo8_Qg@mail.gmail.com>]
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error [not found] ` <BANLkTik2NChYi8hADjCSbjdZeyP_oo8_Qg@mail.gmail.com> @ 2011-04-10 20:00 ` Artyom Tarasenko 2011-04-11 3:16 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 20:00 UTC (permalink / raw) To: Igor Kovalenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko >> <igor.v.kovalenko@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>> On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>>>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>>>>>> qemu/translate-all.c:93 >>>>>>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>>>>>> #12 0x000000000053c756 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: >>>>>>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>>>>>> -------------- >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>> >>>>>>>>>> Search PC... >>>>>>>>>> Search PC... >>>>>>>>>> Search PC... >>>>>>>>>> Search PC... >>>>>>>>>> Search PC... >>>>>>>>>> Search PC... >>>>>>>>>> -------------- >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>> >>>>>>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>>>>>> >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>> -------------- >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>>>>>> -------------- >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>>>>>> -------------- >>>>>>>>>> IN: >>>>>>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>>>>>> 0x00000000011fea2c: 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 >>>>>>>> >>>>>>>> 0x00000000011fea30: retl >>>>>>>> >>>>>>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>>>>>> >>>>>>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>>>>>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >>>>>> >>>>>> Any idea why? retl is not a rare instruction... >>>>> >>>>> Sorry, calls are generated for helpers, so it's not 'jmpl' but the >>>>> call to wrpstate helper. >>>> >>>> And why it doesn't happen in a singlestep mode? >>>> I tried to comment out >>>> cpu_check_irqs(env); >>>> in the helper_wrpstate but it made no difference. The only suspicious >>>> thing left is register bank switching. Is it safe to switch register >>>> banks in the helper function? Shouldn't we end the translation block >>>> before? >>> >>> Not sure if I have seen write to pstate in delay slot, but switching >>> globals with PS_AG appears to be safe. >>> Do you know which bits are changed in the pstate? >> >> Hard to say. With a breakpoint set qemu doesn't crash. >> The breakpoint shows the change from 0x14->0x16. >> So the only difference is that interrupts are getting enabled. No >> register bank change. >> (And now also no cpu_check_irqs(env) call, because I commented it out.) >> >> But given there was a Data Access MMU Miss, I would expect there must >> have beeb a PS_MG switch. >> >> Also the breakpoint makes tcg to cut the translation block before the wrpr: >> >> IN: >> 0x00000000011fea18: rdpr %tick, %o5 >> 0x00000000011fea1c: cmp %o2, %o4 >> 0x00000000011fea20: be %icc, 0x11fea18 >> 0x00000000011fea24: ldub [ %o0 ], %o4 >> -------------- >> IN: >> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >> -------------- >> IN: >> 0x00000000011fea2c: wrpr %g0, %g1, %pstate >> -------------- >> IN: >> 0x00000000011fea30: retl >> -------------- >> IN: >> 0x00000000011fea30: retl >> 0x00000000011fea34: sub %o5, %o3, %o0 >> > > You can try enabling DEBUG_PSTATE to see which bits are changed. I put an additional DPRINTF in the helper and it doesn't get executed at 11fea2c. Only at 11fe9f4 (0x16->0x14). -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 20:00 ` Artyom Tarasenko @ 2011-04-11 3:16 ` Igor Kovalenko 2011-04-11 17:53 ` Artyom Tarasenko 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-11 3:16 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno [-- Attachment #1: Type: text/plain, Size: 10098 bytes --] On Mon, Apr 11, 2011 at 12:00 AM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko > <igor.v.kovalenko@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko >>> <igor.v.kovalenko@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>> On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>>> On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>>>>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>>>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>>>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>>>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>>>>>>> qemu/translate-all.c:93 >>>>>>>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>>>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>>>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>>>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>>>>>>> #12 0x000000000053c756 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: >>>>>>>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>>>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>>>>>>> -------------- >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>> >>>>>>>>>>> Search PC... >>>>>>>>>>> Search PC... >>>>>>>>>>> Search PC... >>>>>>>>>>> Search PC... >>>>>>>>>>> Search PC... >>>>>>>>>>> Search PC... >>>>>>>>>>> -------------- >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>> >>>>>>>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>>>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>>>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>>>>>>> >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>> -------------- >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>>>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>>>>>>> -------------- >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>>>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>>>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>>>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>>>>>>> -------------- >>>>>>>>>>> IN: >>>>>>>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>>>>>>> 0x00000000011fea2c: 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 >>>>>>>>> >>>>>>>>> 0x00000000011fea30: retl >>>>>>>>> >>>>>>>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>>>>>>> >>>>>>>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>>>>>>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >>>>>>> >>>>>>> Any idea why? retl is not a rare instruction... >>>>>> >>>>>> Sorry, calls are generated for helpers, so it's not 'jmpl' but the >>>>>> call to wrpstate helper. >>>>> >>>>> And why it doesn't happen in a singlestep mode? >>>>> I tried to comment out >>>>> cpu_check_irqs(env); >>>>> in the helper_wrpstate but it made no difference. The only suspicious >>>>> thing left is register bank switching. Is it safe to switch register >>>>> banks in the helper function? Shouldn't we end the translation block >>>>> before? >>>> >>>> Not sure if I have seen write to pstate in delay slot, but switching >>>> globals with PS_AG appears to be safe. >>>> Do you know which bits are changed in the pstate? >>> >>> Hard to say. With a breakpoint set qemu doesn't crash. >>> The breakpoint shows the change from 0x14->0x16. >>> So the only difference is that interrupts are getting enabled. No >>> register bank change. >>> (And now also no cpu_check_irqs(env) call, because I commented it out.) >>> >>> But given there was a Data Access MMU Miss, I would expect there must >>> have beeb a PS_MG switch. >>> >>> Also the breakpoint makes tcg to cut the translation block before the wrpr: >>> >>> IN: >>> 0x00000000011fea18: rdpr %tick, %o5 >>> 0x00000000011fea1c: cmp %o2, %o4 >>> 0x00000000011fea20: be %icc, 0x11fea18 >>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>> -------------- >>> IN: >>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>> -------------- >>> IN: >>> 0x00000000011fea2c: wrpr %g0, %g1, %pstate >>> -------------- >>> IN: >>> 0x00000000011fea30: retl >>> -------------- >>> IN: >>> 0x00000000011fea30: retl >>> 0x00000000011fea34: sub %o5, %o3, %o0 >>> >> >> You can try enabling DEBUG_PSTATE to see which bits are changed. > > I put an additional DPRINTF in the helper and it doesn't get executed > at 11fea2c. Only at 11fe9f4 (0x16->0x14). In such cases I would run with -d in_asm,int to have more data to compare two runs. May the patch attached help a bit to add verbose pstate output. Do you have public test case? It is possible to code this delay slot write test but real issue may be corruption elsewhere. -- Kind regards, Igor V. Kovalenko [-- Attachment #2: sparc64-dump-pstate-verbose --] [-- Type: application/octet-stream, Size: 4225 bytes --] sparc64: verbose pstate dump From: Igor V. Kovalenko <igor.v.kovalenko@gmail.com> --- target-sparc/cpu.h | 4 ++++ target-sparc/helper.c | 29 +++++++++++++++++++++++++++-- target-sparc/op_helper.c | 24 ++++++++++++++++++++++++ 3 files changed, 55 insertions(+), 2 deletions(-) diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h index 5cd89a4..e0032dd 100644 --- a/target-sparc/cpu.h +++ b/target-sparc/cpu.h @@ -667,4 +667,8 @@ static inline void cpu_get_tb_cpu_state(CPUState *env, target_ulong *pc, #endif } +#if defined(TARGET_SPARC64) +void pstate_to_string(uint32_t pstate, char *str, size_t str_limit); +#endif + #endif diff --git a/target-sparc/helper.c b/target-sparc/helper.c index e415b22..89da711 100644 --- a/target-sparc/helper.c +++ b/target-sparc/helper.c @@ -1480,6 +1480,26 @@ static void cpu_print_cc(FILE *f, fprintf_function cpu_fprintf, #define REGS_PER_LINE 8 #endif +#if defined (TARGET_SPARC64) +void pstate_to_string(uint32_t pstate, char *str, size_t str_limit) +{ + snprintf(str, str_limit, + "%s%s%s%s%s%s%s%s%s%s%s ", + (pstate & PS_IG) ? " IG" : "", + (pstate & PS_MG) ? " MG" : "", + (pstate & PS_CLE) ? " CLE" : "", + (pstate & PS_TLE) ? " TLE" : "", + (pstate & PS_RMO) ? " RMO" : "", + (pstate & PS_RED) ? " RED" : "", + (pstate & PS_PEF) ? " PEF" : "", + (pstate & PS_AM) ? " AM" : "", + (pstate & PS_PRIV) ? " PRIV" : "", + (pstate & PS_IE) ? " IE" : "", + (pstate & PS_AG) ? " AG" : "" + ); +} +#endif + void cpu_dump_state(CPUState *env, FILE *f, fprintf_function cpu_fprintf, int flags) { @@ -1522,8 +1542,13 @@ void cpu_dump_state(CPUState *env, FILE *f, fprintf_function cpu_fprintf, cpu_fprintf(f, "\n"); } #ifdef TARGET_SPARC64 - cpu_fprintf(f, "pstate: %08x ccr: %02x (icc: ", env->pstate, - (unsigned)cpu_get_ccr(env)); + { + char pstate_string[128]; + pstate_to_string(env->pstate, pstate_string, sizeof (pstate_string)); + cpu_fprintf(f, "pstate: %08x [%s] ccr: %02x (icc: ", + env->pstate, pstate_string, + (unsigned)cpu_get_ccr(env)); + } cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << PSR_CARRY_SHIFT); cpu_fprintf(f, " xcc: "); cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << (PSR_CARRY_SHIFT - 4)); diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index f292309..f01bf53 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -4036,6 +4036,12 @@ void helper_wrpstate(target_ulong new_state) { change_pstate(new_state & 0xf3f); + { + char pstate_string[128]; + pstate_to_string(env->pstate, pstate_string, sizeof (pstate_string)); + DPRINTF_PSTATE("helper_wrpstate pstate=[%s]\n", pstate_string); + } + #if !defined(CONFIG_USER_ONLY) if (cpu_interrupts_enabled(env)) { cpu_check_irqs(env); @@ -4071,6 +4077,12 @@ void helper_done(void) DPRINTF_PSTATE("... helper_done tl=%d\n", env->tl); + { + char pstate_string[128]; + pstate_to_string(env->pstate, pstate_string, sizeof (pstate_string)); + DPRINTF_PSTATE("helper_done pstate=[%s]\n", pstate_string); + } + #if !defined(CONFIG_USER_ONLY) if (cpu_interrupts_enabled(env)) { cpu_check_irqs(env); @@ -4092,6 +4104,12 @@ void helper_retry(void) DPRINTF_PSTATE("... helper_retry tl=%d\n", env->tl); + { + char pstate_string[128]; + pstate_to_string(env->pstate, pstate_string, sizeof (pstate_string)); + DPRINTF_PSTATE("helper_retry pstate=[%s]\n", pstate_string); + } + #if !defined(CONFIG_USER_ONLY) if (cpu_interrupts_enabled(env)) { cpu_check_irqs(env); @@ -4277,6 +4295,12 @@ void do_interrupt(CPUState *env) } env->npc = env->pc + 4; env->exception_index = -1; + + { + char pstate_string[128]; + pstate_to_string(env->pstate, pstate_string, sizeof (pstate_string)); + DPRINTF_PSTATE("do_interrupt pstate=[%s]\n", pstate_string); + } } #else #ifdef DEBUG_PCALL ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-11 3:16 ` Igor Kovalenko @ 2011-04-11 17:53 ` Artyom Tarasenko 2011-04-12 2:14 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-11 17:53 UTC (permalink / raw) To: Igor Kovalenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Mon, Apr 11, 2011 at 5:16 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Mon, Apr 11, 2011 at 12:00 AM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Sun, Apr 10, 2011 at 9:41 PM, Igor Kovalenko >> <igor.v.kovalenko@gmail.com> wrote: >>> On Sun, Apr 10, 2011 at 11:37 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Sun, Apr 10, 2011 at 8:52 PM, Igor Kovalenko >>>> <igor.v.kovalenko@gmail.com> wrote: >>>>> On Sun, Apr 10, 2011 at 10:35 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>> On Sun, Apr 10, 2011 at 7:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>>>> On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>>> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>>>>>>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>>>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@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 0x00000032c2e327f5 in raise () from /lib64/libc.so.6 >>>>>>>>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6 >>>>>>>>>>>> #2 0x000000000051933d 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 0x000000000051a557 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 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10, >>>>>>>>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at >>>>>>>>>>>> qemu/translate-all.c:93 >>>>>>>>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776, >>>>>>>>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989 >>>>>>>>>>>> #7 0x00000000004d4029 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 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066 >>>>>>>>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102 >>>>>>>>>>>> #12 0x000000000053c756 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: >>>>>>>>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1 >>>>>>>>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate >>>>>>>>>>>> -------------- >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>>> >>>>>>>>>>>> Search PC... >>>>>>>>>>>> Search PC... >>>>>>>>>>>> Search PC... >>>>>>>>>>>> Search PC... >>>>>>>>>>>> Search PC... >>>>>>>>>>>> Search PC... >>>>>>>>>>>> -------------- >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1 >>>>>>>>>>>> 0x00000000011fe9fc: mov %o1, %o2 >>>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>>> >>>>>>>>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8 >>>>>>>>>>>> npc=00000000011fe9fc SP=000000000180ae41 >>>>>>>>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc >>>>>>>>>>>> >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fea00: rdpr %tick, %o3 >>>>>>>>>>>> 0x00000000011fea04: cmp %o1, %o2 >>>>>>>>>>>> 0x00000000011fea08: be %icc, 0x11fea00 >>>>>>>>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2 >>>>>>>>>>>> -------------- >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8 >>>>>>>>>>>> 0x00000000011fea14: mov %o2, %o4 >>>>>>>>>>>> -------------- >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fea18: rdpr %tick, %o5 >>>>>>>>>>>> 0x00000000011fea1c: cmp %o2, %o4 >>>>>>>>>>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>>>>>>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>>>>>>>>>> -------------- >>>>>>>>>>>> IN: >>>>>>>>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>>>>>>>>>> 0x00000000011fea2c: 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 >>>>>>>>>> >>>>>>>>>> 0x00000000011fea30: retl >>>>>>>>>> >>>>>>>>>> Since it's a branch instruction I guess this would also be a tcg block boundary. >>>>>>>>> >>>>>>>>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl' >>>>>>>>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem. >>>>>>>> >>>>>>>> Any idea why? retl is not a rare instruction... >>>>>>> >>>>>>> Sorry, calls are generated for helpers, so it's not 'jmpl' but the >>>>>>> call to wrpstate helper. >>>>>> >>>>>> And why it doesn't happen in a singlestep mode? >>>>>> I tried to comment out >>>>>> cpu_check_irqs(env); >>>>>> in the helper_wrpstate but it made no difference. The only suspicious >>>>>> thing left is register bank switching. Is it safe to switch register >>>>>> banks in the helper function? Shouldn't we end the translation block >>>>>> before? >>>>> >>>>> Not sure if I have seen write to pstate in delay slot, but switching >>>>> globals with PS_AG appears to be safe. >>>>> Do you know which bits are changed in the pstate? >>>> >>>> Hard to say. With a breakpoint set qemu doesn't crash. >>>> The breakpoint shows the change from 0x14->0x16. >>>> So the only difference is that interrupts are getting enabled. No >>>> register bank change. >>>> (And now also no cpu_check_irqs(env) call, because I commented it out.) >>>> >>>> But given there was a Data Access MMU Miss, I would expect there must >>>> have beeb a PS_MG switch. >>>> >>>> Also the breakpoint makes tcg to cut the translation block before the wrpr: >>>> >>>> IN: >>>> 0x00000000011fea18: rdpr %tick, %o5 >>>> 0x00000000011fea1c: cmp %o2, %o4 >>>> 0x00000000011fea20: be %icc, 0x11fea18 >>>> 0x00000000011fea24: ldub [ %o0 ], %o4 >>>> -------------- >>>> IN: >>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4 >>>> -------------- >>>> IN: >>>> 0x00000000011fea2c: wrpr %g0, %g1, %pstate >>>> -------------- >>>> IN: >>>> 0x00000000011fea30: retl >>>> -------------- >>>> IN: >>>> 0x00000000011fea30: retl >>>> 0x00000000011fea34: sub %o5, %o3, %o0 >>>> >>> >>> You can try enabling DEBUG_PSTATE to see which bits are changed. >> >> I put an additional DPRINTF in the helper and it doesn't get executed >> at 11fea2c. Only at 11fe9f4 (0x16->0x14). > > In such cases I would run with -d in_asm,int to have more data to > compare two runs. > May the patch attached help a bit to add verbose pstate output. 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? > 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? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-11 17:53 ` Artyom Tarasenko @ 2011-04-12 2:14 ` Igor Kovalenko 2011-04-21 14:57 ` Artyom Tarasenko 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-12 2:14 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Mon, Apr 11, 2011 at 9:53 PM, Artyom Tarasenko <atar4qemu@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-12 2:14 ` Igor Kovalenko @ 2011-04-21 14:57 ` Artyom Tarasenko 2011-04-21 15:44 ` Laurent Desnogues 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-21 14:57 UTC (permalink / raw) To: Igor Kovalenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno [-- Attachment #1: Type: text/plain, Size: 875 bytes --] On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko <igor.v.kovalenko@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/ [-- Attachment #2: test-wrpr.bin --] [-- Type: application/octet-stream, Size: 40 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-21 14:57 ` Artyom Tarasenko @ 2011-04-21 15:44 ` Laurent Desnogues 2011-04-21 19:45 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Laurent Desnogues @ 2011-04-21 15:44 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, peter.maydell, qemu-devel, Aurelien Jarno On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko > <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-21 15:44 ` Laurent Desnogues @ 2011-04-21 19:45 ` Igor Kovalenko 2011-04-21 22:39 ` Laurent Desnogues 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-21 19:45 UTC (permalink / raw) To: Laurent Desnogues Cc: Blue Swirl, peter.maydell, Aurelien Jarno, qemu-devel, Artyom Tarasenko On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues <laurent.desnogues@gmail.com> wrote: > On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >> <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-21 19:45 ` Igor Kovalenko @ 2011-04-21 22:39 ` Laurent Desnogues 2011-04-22 14:14 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Laurent Desnogues @ 2011-04-21 22:39 UTC (permalink / raw) To: Igor Kovalenko Cc: Blue Swirl, peter.maydell, Aurelien Jarno, qemu-devel, Artyom Tarasenko On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues > <laurent.desnogues@gmail.com> wrote: >> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>> <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-21 22:39 ` Laurent Desnogues @ 2011-04-22 14:14 ` Igor Kovalenko 2011-04-25 20:29 ` Aurelien Jarno 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-22 14:14 UTC (permalink / raw) To: Laurent Desnogues Cc: Blue Swirl, peter.maydell, Aurelien Jarno, qemu-devel, Artyom Tarasenko On Fri, Apr 22, 2011 at 2:39 AM, Laurent Desnogues <laurent.desnogues@gmail.com> wrote: > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko > <igor.v.kovalenko@gmail.com> wrote: >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >> <laurent.desnogues@gmail.com> wrote: >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>> <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-22 14:14 ` Igor Kovalenko @ 2011-04-25 20:29 ` Aurelien Jarno 2011-04-26 3:34 ` Igor Kovalenko 2011-04-26 17:02 ` Artyom Tarasenko 0 siblings, 2 replies; 32+ messages in thread From: Aurelien Jarno @ 2011-04-25 20:29 UTC (permalink / raw) To: Igor Kovalenko Cc: Laurent Desnogues, Blue Swirl, qemu-devel, Artyom Tarasenko, peter.maydell 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.desnogues@gmail.com> wrote: > > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko > > <igor.v.kovalenko@gmail.com> wrote: > >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues > >> <laurent.desnogues@gmail.com> wrote: > >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko > >>>> <igor.v.kovalenko@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 aurelien@aurel32.net http://www.aurel32.net ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-25 20:29 ` Aurelien Jarno @ 2011-04-26 3:34 ` Igor Kovalenko 2011-04-26 16:26 ` Artyom Tarasenko 2011-04-26 17:02 ` Artyom Tarasenko 1 sibling, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-26 3:34 UTC (permalink / raw) To: Aurelien Jarno Cc: Laurent Desnogues, Blue Swirl, qemu-devel, Artyom Tarasenko, peter.maydell On Tue, Apr 26, 2011 at 12:29 AM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >> > <igor.v.kovalenko@gmail.com> wrote: >> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >> >> <laurent.desnogues@gmail.com> wrote: >> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >> >>>> <igor.v.kovalenko@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. I looked at my linux kernel builds and do not see any wrpr pstate in delay slot. -- Kind regards, Igor V. Kovalenko ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 3:34 ` Igor Kovalenko @ 2011-04-26 16:26 ` Artyom Tarasenko 2011-04-26 18:07 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-26 16:26 UTC (permalink / raw) To: Igor Kovalenko Cc: Laurent Desnogues, Blue Swirl, qemu-devel, Aurelien Jarno, peter.maydell On Tue, Apr 26, 2011 at 5:34 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Tue, Apr 26, 2011 at 12:29 AM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>> > <igor.v.kovalenko@gmail.com> wrote: >>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>> >> <laurent.desnogues@gmail.com> wrote: >>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>> >>>> <igor.v.kovalenko@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/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 16:26 ` Artyom Tarasenko @ 2011-04-26 18:07 ` Igor Kovalenko 0 siblings, 0 replies; 32+ messages in thread From: Igor Kovalenko @ 2011-04-26 18:07 UTC (permalink / raw) To: Artyom Tarasenko Cc: Laurent Desnogues, Blue Swirl, qemu-devel, Aurelien Jarno, peter.maydell On Tue, Apr 26, 2011 at 8:26 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Tue, Apr 26, 2011 at 5:34 AM, Igor Kovalenko > <igor.v.kovalenko@gmail.com> wrote: >> On Tue, Apr 26, 2011 at 12:29 AM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>> > <igor.v.kovalenko@gmail.com> wrote: >>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>> >> <laurent.desnogues@gmail.com> wrote: >>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>> >>>> <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-25 20:29 ` Aurelien Jarno 2011-04-26 3:34 ` Igor Kovalenko @ 2011-04-26 17:02 ` Artyom Tarasenko 2011-04-26 18:36 ` Blue Swirl 1 sibling, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-26 17:02 UTC (permalink / raw) To: Aurelien Jarno; +Cc: Laurent Desnogues, Blue Swirl, qemu-devel, peter.maydell On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >> > <igor.v.kovalenko@gmail.com> wrote: >> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >> >> <laurent.desnogues@gmail.com> wrote: >> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >> >>>> <igor.v.kovalenko@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 17:02 ` Artyom Tarasenko @ 2011-04-26 18:36 ` Blue Swirl 2011-04-26 19:07 ` Igor Kovalenko 2011-04-27 16:29 ` Artyom Tarasenko 0 siblings, 2 replies; 32+ messages in thread From: Blue Swirl @ 2011-04-26 18:36 UTC (permalink / raw) To: Artyom Tarasenko Cc: Laurent Desnogues, peter.maydell, qemu-devel, Aurelien Jarno On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>> > <igor.v.kovalenko@gmail.com> wrote: >>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>> >> <laurent.desnogues@gmail.com> wrote: >>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>> >>>> <igor.v.kovalenko@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(); + + tcg_gen_mov_tl(r_tmp, cpu_tmp0); + save_state(dc, cpu_cond); + gen_helper_wrpstate(r_tmp); + tcg_temp_free_ptr(r_tmp); + dc->npc = DYNAMIC_PC; + } break; case 7: // tl save_state(dc, cpu_cond); ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 18:36 ` Blue Swirl @ 2011-04-26 19:07 ` Igor Kovalenko 2011-04-26 20:07 ` Blue Swirl 2011-04-27 16:29 ` Artyom Tarasenko 1 sibling, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-26 19:07 UTC (permalink / raw) To: Blue Swirl Cc: Laurent Desnogues, peter.maydell, Aurelien Jarno, Artyom Tarasenko, qemu-devel On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: > On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>> > <igor.v.kovalenko@gmail.com> wrote: >>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>> >> <laurent.desnogues@gmail.com> wrote: >>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>> >>>> <igor.v.kovalenko@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(); > + > + tcg_gen_mov_tl(r_tmp, cpu_tmp0); > + save_state(dc, cpu_cond); > + gen_helper_wrpstate(r_tmp); > + tcg_temp_free_ptr(r_tmp); > + dc->npc = DYNAMIC_PC; > + } > break; > case 7: // tl > save_state(dc, cpu_cond); > This one works (I have tested similar change but tcg_temp_free() would be OK as well) Could anyone please explain why it still works without being in delay slot? Simply pointing at optimizer does not work :( -- Kind regards, Igor V. Kovalenko ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 19:07 ` Igor Kovalenko @ 2011-04-26 20:07 ` Blue Swirl 2011-04-26 21:35 ` Igor Kovalenko 0 siblings, 1 reply; 32+ messages in thread From: Blue Swirl @ 2011-04-26 20:07 UTC (permalink / raw) To: Igor Kovalenko Cc: Laurent Desnogues, peter.maydell, Aurelien Jarno, Artyom Tarasenko, qemu-devel On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>>> > <igor.v.kovalenko@gmail.com> wrote: >>>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>>> >> <laurent.desnogues@gmail.com> wrote: >>>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>>> >>>> <igor.v.kovalenko@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(); >> + >> + tcg_gen_mov_tl(r_tmp, cpu_tmp0); >> + save_state(dc, cpu_cond); >> + gen_helper_wrpstate(r_tmp); >> + tcg_temp_free_ptr(r_tmp); >> + dc->npc = DYNAMIC_PC; >> + } >> break; >> case 7: // tl >> save_state(dc, cpu_cond); >> > > This one works (I have tested similar change but tcg_temp_free() would > be OK as well) Thanks for spotting, that was not intentional. > Could anyone please explain why it still works without being in delay > slot? Simply pointing at optimizer does not work :( save_npc() will call gen_generic_branch() only if dc->npc == JUMP_PC, which is used for delay slot handling. Otherwise gen_generic_branch() is not called and thus brcond does not get used, so the temporary will not be flushed for non-delay slot cases. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 20:07 ` Blue Swirl @ 2011-04-26 21:35 ` Igor Kovalenko 2011-04-27 17:40 ` Blue Swirl 0 siblings, 1 reply; 32+ messages in thread From: Igor Kovalenko @ 2011-04-26 21:35 UTC (permalink / raw) To: Blue Swirl Cc: Laurent Desnogues, peter.maydell, Aurelien Jarno, Artyom Tarasenko, qemu-devel On Wed, Apr 27, 2011 at 12:07 AM, Blue Swirl <blauwirbel@gmail.com> wrote: > On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko > <igor.v.kovalenko@gmail.com> wrote: >> On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>> On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>>>> > <igor.v.kovalenko@gmail.com> wrote: >>>>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>>>> >> <laurent.desnogues@gmail.com> wrote: >>>>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>>>> >>>> <igor.v.kovalenko@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(); >>> + >>> + tcg_gen_mov_tl(r_tmp, cpu_tmp0); >>> + save_state(dc, cpu_cond); >>> + gen_helper_wrpstate(r_tmp); >>> + tcg_temp_free_ptr(r_tmp); >>> + dc->npc = DYNAMIC_PC; >>> + } >>> break; >>> case 7: // tl >>> save_state(dc, cpu_cond); >>> >> >> This one works (I have tested similar change but tcg_temp_free() would >> be OK as well) > > Thanks for spotting, that was not intentional. > >> Could anyone please explain why it still works without being in delay >> slot? Simply pointing at optimizer does not work :( > > save_npc() will call gen_generic_branch() only if dc->npc == JUMP_PC, > which is used for delay slot handling. Otherwise gen_generic_branch() > is not called and thus brcond does not get used, so the temporary > will not be flushed for non-delay slot cases. Great that explains it all, thanks! I think audit over translate.c would be needed, alternatively all main switch temps for sparc64 could be made local as hinted by Laurent - provided there is no significant speed impact. -- Kind regards, Igor V. Kovalenko ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 21:35 ` Igor Kovalenko @ 2011-04-27 17:40 ` Blue Swirl 0 siblings, 0 replies; 32+ messages in thread From: Blue Swirl @ 2011-04-27 17:40 UTC (permalink / raw) To: Igor Kovalenko Cc: Laurent Desnogues, peter.maydell, Aurelien Jarno, Artyom Tarasenko, qemu-devel On Wed, Apr 27, 2011 at 12:35 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote: > On Wed, Apr 27, 2011 at 12:07 AM, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Tue, Apr 26, 2011 at 10:07 PM, Igor Kovalenko >> <igor.v.kovalenko@gmail.com> wrote: >>> On Tue, Apr 26, 2011 at 10:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >>>> On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>>>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>>>>> > <igor.v.kovalenko@gmail.com> wrote: >>>>>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>>>>> >> <laurent.desnogues@gmail.com> wrote: >>>>>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>>>>> >>>> <igor.v.kovalenko@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(); >>>> + >>>> + tcg_gen_mov_tl(r_tmp, cpu_tmp0); >>>> + save_state(dc, cpu_cond); >>>> + gen_helper_wrpstate(r_tmp); >>>> + tcg_temp_free_ptr(r_tmp); >>>> + dc->npc = DYNAMIC_PC; >>>> + } >>>> break; >>>> case 7: // tl >>>> save_state(dc, cpu_cond); >>>> >>> >>> This one works (I have tested similar change but tcg_temp_free() would >>> be OK as well) >> >> Thanks for spotting, that was not intentional. >> >>> Could anyone please explain why it still works without being in delay >>> slot? Simply pointing at optimizer does not work :( >> >> save_npc() will call gen_generic_branch() only if dc->npc == JUMP_PC, >> which is used for delay slot handling. Otherwise gen_generic_branch() >> is not called and thus brcond does not get used, so the temporary >> will not be flushed for non-delay slot cases. > > Great that explains it all, thanks! I think audit over translate.c > would be needed, alternatively all main switch temps for sparc64 could > be made local as hinted by Laurent - provided there is no significant > speed impact. I think there may be a few other cases. Local temps are allocated from stack instead of CPU registers, so there could be a speed impact. It would be better if this case could be detected more reliably instead, for example enhancing the debugging mode for TCG. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-26 18:36 ` Blue Swirl 2011-04-26 19:07 ` Igor Kovalenko @ 2011-04-27 16:29 ` Artyom Tarasenko 2011-04-27 17:41 ` Blue Swirl 1 sibling, 1 reply; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-27 16:29 UTC (permalink / raw) To: Blue Swirl; +Cc: Laurent Desnogues, peter.maydell, qemu-devel, Aurelien Jarno On Tue, Apr 26, 2011 at 8:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: > On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>> > <igor.v.kovalenko@gmail.com> wrote: >>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>> >> <laurent.desnogues@gmail.com> wrote: >>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>> >>>> <igor.v.kovalenko@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(); > + > + tcg_gen_mov_tl(r_tmp, cpu_tmp0); > + save_state(dc, cpu_cond); > + gen_helper_wrpstate(r_tmp); > + tcg_temp_free_ptr(r_tmp); > + dc->npc = DYNAMIC_PC; > + } > break; > case 7: // tl > save_state(dc, cpu_cond); > Yep. This (with tcg_temp_free) passes my tests, thanks! A bonus question: how is immediate case handled? I don't see any explicit "if (IS_IMM)" and yet it seems to produce the expected results for the immediate instructions. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-27 16:29 ` Artyom Tarasenko @ 2011-04-27 17:41 ` Blue Swirl 0 siblings, 0 replies; 32+ messages in thread From: Blue Swirl @ 2011-04-27 17:41 UTC (permalink / raw) To: Artyom Tarasenko Cc: Laurent Desnogues, peter.maydell, qemu-devel, Aurelien Jarno On Wed, Apr 27, 2011 at 7:29 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: > On Tue, Apr 26, 2011 at 8:36 PM, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Tue, Apr 26, 2011 at 8:02 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>> On Mon, Apr 25, 2011 at 10:29 PM, Aurelien Jarno <aurelien@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.desnogues@gmail.com> wrote: >>>>> > On Thu, Apr 21, 2011 at 9:45 PM, Igor Kovalenko >>>>> > <igor.v.kovalenko@gmail.com> wrote: >>>>> >> On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues >>>>> >> <laurent.desnogues@gmail.com> wrote: >>>>> >>> On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote: >>>>> >>>> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >>>>> >>>> <igor.v.kovalenko@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(); >> + >> + tcg_gen_mov_tl(r_tmp, cpu_tmp0); >> + save_state(dc, cpu_cond); >> + gen_helper_wrpstate(r_tmp); >> + tcg_temp_free_ptr(r_tmp); >> + dc->npc = DYNAMIC_PC; >> + } >> break; >> case 7: // tl >> save_state(dc, cpu_cond); >> > > Yep. This (with tcg_temp_free) passes my tests, thanks! > A bonus question: how is immediate case handled? > > I don't see any explicit "if (IS_IMM)" and yet it seems to produce the > expected results for the immediate instructions. Immediates are handled by get_src2(). ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 14:09 ` Artyom Tarasenko 2011-04-10 14:44 ` Blue Swirl @ 2011-04-10 14:59 ` Peter Maydell 2011-04-10 17:31 ` Artyom Tarasenko 1 sibling, 1 reply; 32+ messages in thread From: Peter Maydell @ 2011-04-10 14:59 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: Blue Swirl, qemu-devel, Aurelien Jarno On 10 April 2011 15:09, Artyom Tarasenko <atar4qemu@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error 2011-04-10 14:59 ` Peter Maydell @ 2011-04-10 17:31 ` Artyom Tarasenko 0 siblings, 0 replies; 32+ messages in thread From: Artyom Tarasenko @ 2011-04-10 17:31 UTC (permalink / raw) To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, Aurelien Jarno On Sun, Apr 10, 2011 at 4:59 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 10 April 2011 15:09, Artyom Tarasenko <atar4qemu@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/ ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2011-04-27 17:42 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-10 12:29 [Qemu-devel] tcg/tcg.c:1892: tcg fatal error Artyom Tarasenko
2011-04-10 13:24 ` Aurelien Jarno
2011-04-10 14:09 ` Artyom Tarasenko
2011-04-10 14:44 ` Blue Swirl
2011-04-10 17:48 ` Artyom Tarasenko
2011-04-10 17:57 ` Blue Swirl
2011-04-10 18:35 ` Artyom Tarasenko
2011-04-10 18:52 ` Igor Kovalenko
2011-04-10 19:37 ` Artyom Tarasenko
[not found] ` <BANLkTik2NChYi8hADjCSbjdZeyP_oo8_Qg@mail.gmail.com>
2011-04-10 20:00 ` Artyom Tarasenko
2011-04-11 3:16 ` Igor Kovalenko
2011-04-11 17:53 ` Artyom Tarasenko
2011-04-12 2:14 ` Igor Kovalenko
2011-04-21 14:57 ` Artyom Tarasenko
2011-04-21 15:44 ` Laurent Desnogues
2011-04-21 19:45 ` Igor Kovalenko
2011-04-21 22:39 ` Laurent Desnogues
2011-04-22 14:14 ` Igor Kovalenko
2011-04-25 20:29 ` Aurelien Jarno
2011-04-26 3:34 ` Igor Kovalenko
2011-04-26 16:26 ` Artyom Tarasenko
2011-04-26 18:07 ` Igor Kovalenko
2011-04-26 17:02 ` Artyom Tarasenko
2011-04-26 18:36 ` Blue Swirl
2011-04-26 19:07 ` Igor Kovalenko
2011-04-26 20:07 ` Blue Swirl
2011-04-26 21:35 ` Igor Kovalenko
2011-04-27 17:40 ` Blue Swirl
2011-04-27 16:29 ` Artyom Tarasenko
2011-04-27 17:41 ` Blue Swirl
2011-04-10 14:59 ` Peter Maydell
2011-04-10 17:31 ` Artyom Tarasenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).