Re: [PATCH v2 2/6] target/i386: Use cpu_unwind_state_data for tpr access

[Richard Henderson]

On 10/27/22 22:22, Claudio Fontana wrote:
> On 10/27/22 12:02, Richard Henderson wrote:
> > +    /* Per x86_restore_state_to_opc. */
> > +    if (TARGET_TB_PCREL) {
> > +        return (env->eip & TARGET_PAGE_MASK) | data[0];
> > +    } else {
> > +        return data[0] - env->segs[R_CS].base;
>
> here we switch from taking cs_base from the TranslationBlock to taking it from 
> env-> .
>
> I traced the tb->cs_base use back to
>
> cpu_exec() and cpu_exec_step_atomic()
>
> and from there it seems ok, as the sequence is
>
> cpu_get_tb_cpu_state(cpu->env_ptr, &pc, &cs_base, &flags), which gets it from 
> env,
>
> followed by
>
> tb_gen_code(...cs_base) which sets the TranslationBlock cs_base, and 
> tb->cs_base does
> not seem to change again.
Correct.  I wondered if I'd made a mistake by not returning the TB located during the 
search, but it doesn't seem to have mattered for the two users.

> I mention this in the case there can be some weird situation in which env and 
> tb can
> end up not being consistent, does a TranslationBlock that is initialized with a 
> certain
> cs_base from the env that contains user code to load / change the CS segment 
> base
> potentially constitute a problem?
The only way to load/change a CS segment base is a branch instruction, which will of 
course end the TB.  There should be no way to change CS that continues the TB.


r~