qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 17/23] target/i386: Create gen_jmp_rel


From: Richard Henderson
Subject: Re: [PATCH v2 17/23] target/i386: Create gen_jmp_rel
Date: Fri, 30 Sep 2022 17:53:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 9/21/22 06:06, Paolo Bonzini wrote:
On Tue, Sep 6, 2022 at 12:09 PM Richard Henderson
<richard.henderson@linaro.org> wrote:

Create a common helper for pc-relative branches.
The jmp jb insn was missing a mask for CODE32.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

(Oops, my remark the previous patch should still have pointed to gen_jmp_tb).

In gen_jz_ecx_string, in the translation for LOOPNZ/LOOPZ/LOOP/JECXZ
and in i386_tr_tb_stop there is:

-    gen_jmp_tb(s, s->pc - s->cs_base, 1);
+    gen_jmp_rel(s, MO_32, 0, 1);

What happens if the instruction's last byte is at 0xffff? Wraparound
in the middle of an instruction is generally undefined, but I think it
should work if the instruction does not cross the 64K/4G limit (and on
real hardware, which obeys segment limits unlike TCG, said limit must
be 64K/4G of course).

In other words, why MO_32 and not "CODE32(s) ? MO_32 : MO_16"?

I believe it really should be s->dflag, which makes all users of the function pass dflag (the manual consistently talks about "operand size"). At which point this parameter goes away and gen_jmp_rel grabs the operand size from DisasContext.

Also, pre-existing bug vs CODE64 here -- operand size is always 64-bits for 
near jumps.


r~



reply via email to

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