Re: qemu_plugin_insn_disas() versus -cpu

[Peter Maydell]

On Tue, 31 Mar 2020 at 14:35, Marc Hacin <address@hidden> wrote:
> I am using qemu_plugin_insn_disas() in a TCG plugin.
> Some floating point instructions are properly translated to host code,
> as it works in the emulator, but are translated to ".byte " by
> qemu_plugin_insn_disas().
>
> It seems that the capstone library behind qemu_plugin_insn_disas does
> not support that PowerPC core.
>
> But as the emulator translates right the guest code, I wonder why
> capstone is required.

The code for emulation does "take these bytes, and generate
QEMU TCG intermediate representation opcodes that implement
the meaning of the insns". The code for disassembly does
"take these bytes, and generate a human-readable string".
Within QEMU they're entirely separate (we call one the
"translator" and the other the "disassembler"), and the
disassembler is usually a bit of 3rd party code (we have
some in-tree code from an old binutils, and we use capstone).

> Isn't it possible for the translator to also build
> a string, disassembling of any guest instruction ? So as to be
> conformant with configure'd selected targets.

This would be a fair bit of extra work: the structure of the
two pieces of code is similar in some ways but adding in
support for disassemble-to-string to the translator code
would be awkward. We use third party disassembly
libraries because we don't want to have to reinvent that
wheel, and the only thing we use a disassembler for is
tracing output for debug purposes, so it's not critical
if it doesn't correctly handle some insns on some targets.
Plus as a bonus, having the disassembly be from 3rd party code
means you don't get confused by having a bug in the translator
which mis-decodes something but looks correct in the dissasembly
because it has the identical bug.

> Or else, use of the GNU binutils code ?

We do that where we can, but the problem is that newer versions
of GNU binutils are GPL v3-only, which is not compatible with
QEMU's GPL-v2 license. So we use binutils code from the last
GPLv2 release, but obviously this is missing handling for
anything added to the target architecture after that date.
You're right that ideally we'd be able to use binutils code
here, but unfortunately the licensing doesn't allow it.
Capstone is the best compromise we've found between
"license is compatible" and "covers architectures we want"
but it's turned out not to be kept as up-to-date as we'd
first hoped it would be when we started using it.

thanks
-- PMM