qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [RFC] Disassembler options going forward


From: Richard Henderson
Subject: [Qemu-devel] [RFC] Disassembler options going forward
Date: Thu, 14 Feb 2013 13:10:33 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 02/13/2013 06:28 PM, Anthony Liguori wrote:
> QEMU is GPLv2 only so we can't take GPLv3 code.  We're stuck on binutils
> code that predates the v3 relicense.

Ok, this is something that's going to bite us more and more.

We need *some* solution that allows us to disassemble current cpus.
What we've got in disas/ is, except for really old cpus, completely out
of date:

 * x86 missing all opcodes from sse4 and beyond,
 * s390 missing tons of opcodes (I filled in some, but not all)
 * ppc missing tons of opcodes (2.06 and later?)

The only options I can see going forward are

 1) Provide a configure time option to link to the "system" libopcodes.
 2) Use someone else's (bsd licensed?) disassember.
 3) Rearrange relevant translators so that they can disassemble and
    not translate.

The complete solution could be a combination of all three.

To me, option (1) means that qemu the project is not "infecting" the
binary with GPLv3, but requiring the user to make that choice.  Which
seems fine; those that have moral objections to v3 can simply not use
that configure option.  It's a bit awkward that most distributions don't
package up libopcodes for install, but if you manually build binutils
you'll have it done.

I hope we'll all agree that option (3) is not ideal, since having a
separate disassembler works as a check against the translator.  However,
for odd parts that will never be a host it's not a totally unreasonable
solution, as it at least provides *some* disassembly.

As for option (2), I'm not even sure what to suggest.  I suppose there's
some part of LLVM that does textual disassembly.  Whether we want to
drag that in as a submodule or just require it to be installed and
notice it at configure time, I have no opinion.  But because of the odd
parts, (2) can't be the only option.

But most of all I think we should have a plan.


r~



reply via email to

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