Re: [Qemu-devel] Actual TB code doesn't look like what was intended (TCG issue)?

[Max Filippov]

> Here are my rules of thumb for generating code where the code
> generated might change based on some bit of CPU state:
>
> 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 (or tb->pc or tb->cs_base)
>      (and gen_intermediate_code_internal() must read and
>      use the value in tb->tb_flags, not the one in env)

So if changing a bit of context does not cause TB invalidation then it
must be captured in cpu_get_tb_cpu_state and
gen_intermediate_code_internal must use that captured value?

>  (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), and also
>      if the change is the result of some instruction then
>      you must terminate the TB after that instruction.
>      This is often used for things that rarely change and/or
>      where you can't fit the whole value into tb_flags.
> The reason for this is that 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.
>
> This is the xtensa port at
> http://jcmvbkbc.spb.ru/git/?p=dumb/qemu-xtensa.git;a=shortlog;h=refs/heads/xtensa
> right?

Yes.

> It looks like you're breaking these rules with a lot of
> the fields in your DisasContext. (Most obviously, you
> need to translate code from tb->pc, not env->pc, and
> xtensa_get_ring() and xtensa_get_cring() should not read
> from env->sregs[PS]. But you should be clear for every
> field in DisasContext which category it falls into.)

Thank you Peter. Will go rearrange that mess.

-- 
Thanks.
-- Max