On 29 June 2017 at 19:20, Philippe Mathieu-Daudé <f4...@amsat.org> 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
