Re: [Qemu-devel] [PATCH 0/4] new Blackfin QEMU port

[Peter Maydell]

On 1 February 2011 09:38, Alexander Graf <address@hidden> wrote:
> On 01.02.2011, at 05:19, Mike Frysinger wrote:
>> On Mon, Jan 31, 2011 at 09:00, Edgar E. Iglesias wrote:
>>> * cpu_get_tb_cpu_state() doesn't define any tb flags?
>>
>> no idea what this func is supposed to do
>
> Qemu uses the tb flags as identifier for a translation block.
> So a tb is only reused, when the physical address, flags and
> code segment (x86 thing) are equal.

Put another way, when you are generating code, if the code
you generate will change based on the contents of something
in the CPUState struct, then the bit of CPUState you are
looking at has to be one of:
 (1) encoded in the TB flags
      (as Alexander says, "is CPU in privileged mode"
      is a popular choice)
 (2) always constant for the life of the simulation
      (eg env->features if you have some sort of
      "target feature support" flags)
 (3) specially handled so that when it changes then
      all TBs or at least all affected TBs are flushed
      (env->breakpoints is in this category)

...because the CPUState you're passed in is not guaranteed
to be the state of the CPU at the PC which you are starting
translation from.

Otherwise you have case
 (4) a very hard to track down bug (qemu will in some
cases ask you to retranslate a block and if you don't
generate binary-identical output the second time around
things will go badly wrong)

So for instance here:

+static void gen_hwloop_check(DisasContext *dc)
+{
+    bool loop1, loop0;
+    int endl;
+
+    loop1 = (dc->pc == dc->env->lbreg[1]);
+    loop0 = (dc->pc == dc->env->lbreg[0]);

I suspect that this check of pc against the lbreg[]
values should be being done in the generated code,
not at translate time.

-- PMM