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~
