Peter Maydell <[email protected]> writes: > On 14 February 2013 21:10, Richard Henderson <[email protected]> wrote: >> 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. > > 4) Since we only do disassembly for debug logging, have our debug > logging just log hex, with postprocessing by a script that runs > objdump or something
Ack. A simple binary format would be nice too since you probably want the traces to be as small a possible. > >> 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'm not hugely convinced by the idea of "here's a configure switch > to produce binaries you can't legally distribute". > >> 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. > > I had a look at the LLVM disassembler the other day. From a quick > glance it seems like LLVM drives the disassembler off a generalised > machine description language (which it also uses for various other > things), so getting the disassemblers would also require us to > pull in quite a bit of LLVM infrastructure for parsing the machine > descriptions. It didn't look particularly easy, but this is just > from 15 minutes browsing a source tree, so if anybody more LLVM > aware here has an opinion do say. LLVM is a beast. I played around with using cfront to make a QAPI front end and it took 4-5G worth of dispatch just to get it building. Regards, Anthony Liguori > >> But most of all I think we should have a plan. > > Agreed. > > -- PMM
