Il 27/05/2013 01:45, Laszlo Ersek ha scritto:
> I believe aflag++ is incorrect if the current default address size for
> 32-bit is 16-bit (ie. (s->code32 & 1) == 0).
... which cannot happen. :)
(Sorry, should have been more verbose).
See cpu_x86_load_seg_cache:
#ifdef TARGET_X86_64
if ((env->hflags & HF_LMA_MASK) && (flags & DESC_L_MASK)) {
/* long mode */
env->hflags |= HF_CS32_MASK | HF_SS32_MASK | HF_CS64_MASK;
env->hflags &= ~(HF_ADDSEG_MASK);
} else
#endif
{
/* legacy / compatibility case */
new_hflags = (env->segs[R_CS].flags & DESC_B_MASK)
>> (DESC_B_SHIFT - HF_CS32_SHIFT);
env->hflags = (env->hflags & ~(HF_CS32_MASK | HF_CS64_MASK)) |
new_hflags;
}
This is the only place where HF_CS64_MASK is added to env->hflags. Then:
dc->code64 = (flags >> HF_CS64_SHIFT) & 1;
#define CODE64(s) ((s)->code64)
Paolo
In this case the first XOR
> (seeing the 0x67 prefix) flips it to 1, and the increment would change
> it to 2. aflag==2 corresponds to 64-bit address, but in 64-bit mode with
> the 0x67 prefix we must choose 32-bit.
>
> (IOW in 32-bit mode the meaning of the 0x67 prefix is not absolute but
> relative.)
>
> Laszlo
>
>
