Re: [Qemu-devel] [PATCH] Revived GUEST_BASE support for usermode emulation targets [v3]

[malc]

On Tue, 5 May 2009, Riku Voipio wrote:

> On Tue, May 05, 2009 at 02:53:31PM +0100, Paul Brook wrote:
> > On Tuesday 05 May 2009, Riku Voipio wrote:
> > > +++ b/tcg/x86_64/tcg-target.c
> > > @@ -616,15 +616,15 @@ static void tcg_out_qemu_ld(TCGContext *s, const
> > >          /* movzbl */
> > > -        tcg_out_modrm_offset(s, 0xb6 | P_EXT, data_reg, r0, 0);
> > > +        tcg_out_modrm_offset(s, 0xb6 | P_EXT, data_reg, r0, GUEST_BASE);
> 
> > This breaks when GUEST_BASE is large.
> 
> usually we don't set it to very large, just high enough to overcome
> mmap_min_addr limits.

Yes, it would break, i failed to considered x86_64, never used it in fact, 
so was unaware that displacements are constrained there.

Anyway, AMD64 Architecture Programmer's Manual Volume 1: Application 
Programming says:

<quote>
Displacements and Immediates. In general, the maximum size of address
displacements and immediate operands is 32 bits. They can be 8, 16, or
32 bits in size, depending on the instruction or, for displacements,
the effective address size. In 64-bit mode, displacements are
sign-extended to 64 bits during use, but their actual size (for value
representation) remains a maximum of 32 bits. The same is true for
immediates in 64-bit mode, when the operand size is 64 bits. However,
support is provided in 64-bit mode for some 64-bit displacement and
immediate forms of the MOV instruction.
</quote>
 
> > 32-bit x86 is probably ok because GUEST_BASE is always a 32-bit value. 
> > This is not true for x86-64. Incidentally tcg_out_modrm doesn't seem 
> > to check this, and silently generates broken code.
> 
> Should we rather check for a mazimum size on guest_base or revert to the 
> lea -based version?

Things should work the way they are in your latest patch on x86 and should
be done the way it's done in the original submission (mov + add) for
x86_64.

-- 
mailto:address@hidden