Marcelo Tosatti wrote:
> 1) add is storing the result in the wrong register
>
> 6486: 66 64 89 3e 72 01 mov %edi,%fs:0x172
> 648c: 66 be 8d 03 00 00 mov $0x38d,%esi
> 6492: 66 c1 e6 04 shl $0x4,%esi
> 6496: 66 b8 98 0a 00 00 mov $0xa98,%eax
> 649c: 66 03 f0 add %eax,%esi
>
> The destination for the add is "%esi", but the emulation stores the
> result in eax, because:
>
> if ((c->d & ModRM) && c->modrm_mod == 3) {
> u8 reg;
> c->dst.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
> c->dst.ptr = decode_register(c->modrm_rm, c->regs,
> c->d & ByteOp);
> }
>
> modrm_reg contains "6", which is the correct register index, but
> modrm_rm contains 0, so the result is stored in "eax" (see hack).
>
What version are you looking at? Current code doesn't have exactly this.
But register-in-modrm decoding is a mess, yes. I think the best thing
is to have decode_modrm() accept a struct operand parameter and decode
into that.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
