On 26 December 2013 19:10, Richard Henderson <r...@twiddle.net> wrote: > On 12/26/2013 10:58 AM, Peter Maydell wrote: >>> @@ -6231,7 +6214,7 @@ static target_ulong disas_insn(CPUX86State *env, >>> DisasContext *s, >>> exception */ >>> gen_op_jmp_T0(); >>> /* pop selector */ >>> - gen_op_addl_A0_im(1 << dflag); >>> + gen_add_A0_im(s, 1 << dflag); >> >> Why is it OK that we no longer zero extend the result of >> the add from 32 to 64 bits if CODE64(s) ? Previously we >> did the extend unconditionally. > > I can only imagine that's a bug, to have suddenly zapped the high 32-bits of > the address from which we're loading. Indeed, even this is probably not 100% > correct wrt stack segment wraparound.
Looking a bit more closely, is it even possible for code64 to be 1 if we're in real or vm86 mode? If not, then the behaviour here is unchanged (ie still always zero extends). > Probably better to generate both addresses from ESP and ESP+C from scratch, > using gen_lea_v_seg. Agreed (compare gen_popa which does get the multiple-pops behaviour right I think). -- PMM
