[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Disassembler options going forward
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [RFC] Disassembler options going forward |
Date: |
Thu, 14 Feb 2013 21:51:20 +0000 |
On Thu, Feb 14, 2013 at 9:10 PM, Richard Henderson <address@hidden> wrote:
> 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?)
Sparc64 is probably missing a few opcodes too.
>
> 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.
4) Ask binutils' authors of x86, s390 and ppc disassembly code (or
FSF) to dual license their code as GPLv2+ and GPLv3. May be difficult.
5) Relicense QEMU as GPLv3. Need to reimplement some parts.
>
> 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~
>