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

[Anthony Liguori]

Peter Maydell <address@hidden> writes:

> On 14 February 2013 21:10, Richard Henderson <address@hidden> 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