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

[Max Filippov <jcmvbkbc@gmail.com>]

> 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)
>  (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?
> 
> 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.)

Peter you are right, I've moved ring/cring into tb_flags and the issue has gone. Thank you.
I'd like to document it somewhere in http://wiki.qemu.org/Documentation, can you suggest a good place for it?

-- Max