Fwd: [Qemu-devel] Weird behavior while using the instruction counter

["Luis Pureza" <pureza@student.dei.uc.pt>]

By mistake I sent the following message to Paul Brook's private address.
Apologies for that.

Luis Pureza

---------- Forwarded message ----------
From: Luis Pureza <pureza@student.dei.uc.pt>
Date: Thu, Jul 24, 2008 at 3:42 PM
Subject: Re: [Qemu-devel] Weird behavior while using the instruction counter
To: Paul Brook <paul@codesourcery.com>


On Thu, Jul 24, 2008 at 3:02 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > No. You're assuming the IO trap occurs on the last instruction, which not
>> > true.  The problem is that cpu_exec_nocache introduces a second TB with
>> > the same lookup key(pc+flags). cpu_io_recompile (and possibly other
>> > places) assume the currently executing TB is the only tb that matches. It
>> > needs to invalidate the original TB (if it exists) as well as the
>> > uncached one.
>>
>> Obviously, you're right. I was testing with blocks of a single
>> instruction. What do you think of this:
>>
>>  if (tb != &tbs[0] && (tb - 1)->pc == tb->pc) {
>>         tb_phys_invalidate(tb - 1, -1);
>>  }
>
> No. There's no guarantee that the TBs are consecutive.

What about this then:

tb2 = env->tb_jmp_cache[tb_jmp_cache_hash_func(tb->pc)];
if (tb2) {
   tb_phys_invalidate(tb2, -1);
}

added to the same place. This way, tb_find_fast() will never return
the old TB again.

Luis Pureza