qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] disas: Disassembler disagrees with translator over inst


From: Peter Maydell
Subject: Re: [Qemu-devel] disas: Disassembler disagrees with translator over instruction decoding
Date: Thu, 29 Jun 2017 19:42:08 +0100

On 29 June 2017 at 19:20, Philippe Mathieu-Daudé <address@hidden> wrote:
> I got this "Disassembler disagrees with translator over instruction
> decoding" message asking to get reported here.
>
> What happens here is coreboot incorrectly emits a Pentium2 instruction while
> I'm running qemu with a Pentium cpu. I didn't know what to expect but got
> this error message, then qemu keep looping using 100% cpu.

So the primary cause of this message is when the disassembler
(ie disas/) says "the insn at this PC is X bytes long", but
the size it got passed by the translator in target/whatever
is not X. Since the size passed to target_disas() is usually
"start PC of insn minus PC of insn after it's been advanced
by the decoder", this works OK for insns correctly understood
and also for insns which are fixed-length (or easily-identified
length like Thumb). But it doesn't work if insns are variable
length and the decoder bails out to "illegal instruction"
early, like the i386 decoder does.

(Specifically in this instance we check for CPUID_CMOV and
bail out before doing the cpu_ldub_code() of the modrm byte.)

I think we should either:
 (1) be a lot more careful in decoders for variable-length
insn sets that we really read all the bytes of an insn before
deciding it's an illegal encoding
 (2) decide that this warning message is more trouble than it's
worth and get rid of it entirely (has it ever genuinely
flagged up a bug for anybody?)
 (3) provide a mechanism for the decoder to say "I didn't
actually decode the whole insn so I have no idea how big it is"

There are probably some annoying corner cases involving
variable length instructions that cross page boundaries
where the 2nd page is not readable and the decoder bails
out early: does real hardware give an insn abort or an
illegal insn exception in that kind of case?

thanks
-- PMM



reply via email to

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