Re: qemu disassembler status

[Thomas Huth]

On 11/09/2020 23.50, Richard Henderson wrote:
> Taking this to the mailing list, since there are others who have expressed
> interest in the topic.
> 
> 
> On 9/7/20 11:36 AM, Peter Maydell wrote:
>> Hi; I have a feeling we've discussed this on irc at some point
>> in the past, but I've forgotten the details, so I figured if I
>> wrote an email I might be able to find it again later...
>>
>> So, currently we have:
>>  * some disassemblers in the tree (old binutils, and some other
>>    things)
>>  * in particular one of those is the aarch64 libvixl, which is
>>    3rd-party code that we occasionally manually import/update
>>  * capstone, which is a submodule
>>
>> Am I right in thinking that you've suggested that ideally we should
>> use libllvm directly as our disassembler (with the hope that that
>> will have better coverage of different architectures and be more
>> up-to-date than capstone)?
> 
> I've spent a couple of days poking at the llvm disassembler.
> 
> As a general-purpose disassembler, it's less than ideal.
> 
> (1) The disassembler is not "inclusive".  You present it with
>     a specific cpu configuration, and anything that cpu does
>     not support is considered invalid.  There is no "maximum"
>     configuration that attempts to decode any insn in the ISA.
> 
> (2) All configuration is done via strings, so you can't
>     programatically tell what's supported.  I think they're
>     expecting all of these strings to come from the
>     command line.
> 
> (3) If you include a unrecognized cpu feature, an error is
>     printed to stderr.  Which suggests that we would easily
>     wind up with problems between llvm versions.
> 
> (4) "Probing" what is supported with a particular version is
>     done via "+help", which prints what is supported to stdout.

Ouch, that sounds ugly, indeed.

> In the short-term, I guess I'll look into updating our capstone branch.  And
> possibly reject using the system version -- either use the git submodule or
> nothing.

Sounds like the best option right now.

Is capstone good enough already to replace libvixl?

And what about the other old disassemblers that we have in disasm/ ?
Could some of them be replaced by capstone, too?
Or shall we try to pursue the idea of adding a GPLv3 helper program that
could link against recent versions of libopcode?

And what about new disassembler files like the Loongson 2F disassembler
that has been proposed two months ago? Shall we enforce that people try
to add such stuff to capstone first?

 Thomas