On 10/27/22 22:13, Richard Henderson wrote:
> 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~
Reviewed-by: Claudio Fontana <cfont...@suse.de>
