On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf <agraf@xxxxxxx> wrote: > > > On 08.09.2012, at 10:06, Blue Swirl <blauwirbel@xxxxxxxxx> wrote: > >> On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: >>> On 09/05/2012 10:04 PM, Blue Swirl wrote: >>>> >>>> Reinventing a disassembler for ever growing x86 assembly is >>>> no fun. >>> >>> We can try linking to a disassembler library. I use udis86 to >>> disassemble instructions in kvm tracepoints >>> (http://udis86.git.sourceforge.net/git/gitweb.cgi?p=udis86/udis86;a=shortlog), >>> it's maintained but not heavily so. >> >> I think commonality with KVM would be preferred. The library looks >> neat and based on changelog, more actively developed than BSD DDB. >> >>> >>> Of course for non-x86 we'd need to continue using binutils; this is >>> about copying code vs. libraries, not about licensing. >> >> For most architectures, pre-GPLv3 binutils is good enough since the >> instruction set does not change anymore. Maybe only PPC and Sparc64 >> still change besides x86. New CPUs types more recent than 2007 will >> have problems. > > Alternatively we could try to run the disassembler in a different process, right? For qemu.log this would be doable and even improve performance since only binary data would be transferred. But for monitor disassembly command x/i it may be too clumsy. There's some overlap with GDB support, so maybe we could deprecate monitor disassembly. > > Alex > >> >>> >>> >>> -- >>> error compiling committee.c: too many arguments to function >> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
