On Mon, Jul 29, 2013 at 3:01 AM, Aurelien Jarno <aurel...@aurel32.net> wrote: > On Thu, Jul 11, 2013 at 08:01:19AM +0400, Max Filippov wrote: >> On Thu, Jul 11, 2013 at 6:35 AM, Max Filippov <jcmvb...@gmail.com> wrote: >> > Hi Peter, >> > >> > I suddenly found qemu built with debug enabled aborting with an assertion >> > on one of xtensa tests: >> > >> > qemu-system-xtensa -M sim -cpu dc232b -nographic -semihosting -kernel >> > ./test_sr.tst >> > QEMU 1.4.50 monitor - type 'help' for more information >> > (qemu) QEMU 1.4.50 monitor - type 'help' for more information >> > (qemu) qemu-system-xtensa: tcg/tcg.c:1673: temp_save: Assertion >> > `s->temps[temp].val_type == 2 || s->temps[temp].fixed_reg' failed. >> >> Déjà vu: >> >> commit e5138db510efb61523be92c225d8c65eb985fff0 >> Author: Aurelien Jarno <aurel...@aurel32.net> >> Date: Sat Nov 24 11:53:55 2012 +0100 >> >> tcg: mark local temps as MEM in dead_temp() >> >> In dead_temp, local temps should always be marked as back to memory, >> even if they have not been allocated (i.e. they are discared before >> cross a basic block). >> >> It fixes the following assertion in target-xtensa: >> >> qemu-system-xtensa: tcg/tcg.c:1665: temp_save: Assertion >> `s->temps[temp].val_type == 2 || s->temps[temp].fixed_reg' failed. >> Aborted >> >> > This happens in the mainline as well, bisection points to the following >> > commit: >> > >> > commit 378df4b23753a11be650af7664ca76bc75cb9f01 >> > Author: Peter Maydell <peter.mayd...@linaro.org> >> > Date: Fri Feb 22 18:10:03 2013 +0000 >> > >> > Handle CPU interrupts by inline checking of a flag >> > >> > >> > I have the following traces when it happens, any idea of what could go >> > wrong? >> > >> > OP: >> > ld_i32 loc0,env,$0xffffffffffffffc8 >> > movi_i32 tmp1,$0x0 >> > brcond_i32 loc0,tmp1,ne,$0x0 >> > ---- 0xd0000fde >> > >> > ---- 0xd0000fe0 >> > movi_i32 tmp1,$0xd0000fe0 >> > movi_i32 tmp2,$0x1 >> > movi_i32 tmp3,$0x2 >> > movi_i64 tmp4,$advance_ccount >> > call tmp4,$0x0,$0,env,tmp3 >> > movi_i64 tmp4,$window_check >> > call tmp4,$0x0,$0,env,tmp1,tmp2 >> > movi_i32 ar4,$0x0 >> > >> > ---- 0xd0000fe2 >> > movi_i32 tmp1,$0xd00003f0 >> > qemu_ld32 ar2,tmp1,$0x0 >> > >> > ---- 0xd0000fe5 >> > movi_i32 tmp1,$0xd0000470 >> > qemu_ld32 ar3,tmp1,$0x0 >> > >> > ---- 0xd0000fe8 >> > mov_i32 tmp1,ar2 >> > qemu_st32 ar3,tmp1,$0x0 >> > >> > ---- 0xd0000fea >> > movi_i32 tmp1,$0xd0000fea >> > movi_i32 tmp2,$0x0 >> > movi_i32 tmp3,$0x4 >> > movi_i64 tmp4,$advance_ccount >> > call tmp4,$0x0,$0,env,tmp3 >> > movi_i64 tmp4,$exception_cause >> > call tmp4,$0x0,$0,env,tmp1,tmp2 >> > mov_i32 env,ar4 > > I think it might be a bug in the current TCG code not handling the case > of writing to a fixed register TCG temp as it is a quite uncommon case. > I will try to look at the code, but it would be easier if you can > provide a way to reproduce the issue. > > On the other hand, is it correct to override the value of the env > pointer, with a value from a CPU register? This doesn't smell good and > looks like it can be a security issue.
Aurelien, thanks for your reply. I've also noticed that strange 'mov_i32 env,ar4' and dug it a bit: this was caused by an opcode referencing unimplemented SR. I've posted a fix (http://marc.info/?l=qemu-devel&m=137440837125020&w=2). This fix also fixed that abort. The 'mov_i32 env,ar4' instruction is unreachable because an invalid opcode exception is raised just above it. -- Thanks. -- Max