qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]