Re: [Qemu-devel] [PATCH 2/2] PPC: Fail on leaking temporaries

[Alexander Graf]

On 19.01.2014, at 17:51, Peter Maydell <address@hidden> wrote:

> On 19 January 2014 16:32, Alexander Graf <address@hidden> wrote:
>> When QEMU gets compiled with --enable-debug-tcg we can check for temporary
>> leakage. Implement the necessary target code for this and fail emulation
>> when we hit a leakage.
>> 
>> This hopefully ensures that we don't get new leaks.
>> 
>> Signed-off-by: Alexander Graf <address@hidden>
>> ---
>> target-ppc/translate.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>> 
>> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
>> index 02cd18e..759133c 100644
>> --- a/target-ppc/translate.c
>> +++ b/target-ppc/translate.c
>> @@ -10412,6 +10412,7 @@ static inline void 
>> gen_intermediate_code_internal(PowerPCCPU *cpu,
>>         max_insns = CF_COUNT_MASK;
>> 
>>     gen_tb_start();
>> +    tcg_clear_temp_count();
>>     /* Set env in case of segfault during code fetch */
>>     while (ctx.exception == POWERPC_EXCP_NONE
>>             && tcg_ctx.gen_opc_ptr < gen_opc_end) {
>> @@ -10511,6 +10512,12 @@ static inline void 
>> gen_intermediate_code_internal(PowerPCCPU *cpu,
>>              */
>>             break;
>>         }
>> +        if (tcg_check_temp_count()) {
>> +            fprintf(stderr, "Opcode %02x %02x %02x (%08x) leaked 
>> temporaries\n",
>> +                    opc1(ctx.opcode), opc2(ctx.opcode), opc3(ctx.opcode),
>> +                    ctx.opcode);
>> +            exit(1);
> 
> Exiting is pretty harsh; ARM just warns and continues. In my
> experience most of the TCG temp leaks happen on paths
> where the decoder has done some setup, then discovered
> later that the instruction should throw an exception and
> the exception generating code path exits the decoder function
> early without freeing the TCG temp. Since we always finish
> the TB immediately in this case, it's never possible to actually
> run out of TCG temporaries. So I felt that continuing was better
> than gratuitously stopping the guest from running in these cases,
> since it's hard to be certain you've caught them all unless you
> care to run the decoder through the complete set of instructions
> from 0x00000000 to 0xffffffff. (That is actually possible in less
> than geological time if you write a special purpose test harness.)

Well, the check only ever happens when QEMU gets compiled with 
--enable-debug-tcg, so I figured it's easier for me to catch new problems or 
problems with unit tests if we get a harsh abort :).


Alex