[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 56/60] target-i386: Tidy gen_add_A0_im
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH v2 56/60] target-i386: Tidy gen_add_A0_im |
Date: |
Thu, 26 Dec 2013 22:34:47 +0000 |
On 26 December 2013 19:10, Richard Henderson <address@hidden> 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