On Thu, Feb 14, 2013 at 9:10 PM, Richard Henderson <r...@twiddle.net> 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~ >
