Re: [Qemu-devel] qemu aborts with temp_save: Assertion `s->temps[temp].val_type == 2 || s->temps[temp].fixed_reg' failed

[Max Filippov]

On Mon, Jul 29, 2013 at 3:01 AM, Aurelien Jarno <address@hidden> 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 <address@hidden> 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 <address@hidden>
>> 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 <address@hidden>
>> > 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