On 01.02.2011, at 11:31, Peter Maydell wrote:
> On 1 February 2011 09:38, Alexander Graf <ag...@suse.de> 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.
Ouch. Yes. General rule: never access env from translate.c :). If you need to
check for anything, go through the tb flags. Or generate inline code that does
the checks.
Thanks for the nice explanation Peter :)
Alex
