Re: qemu disassembler status

[Richard Henderson]

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.


>> For llvm, I would most definitely not use a submodule.  Disassembly is for
>> developers, not end users, and I think we can insist on support libraries 
>> being
>> installed.
> 
> Disassembly is for end users too.  I think we need a submodule.
> (This also means we can have newer versions than whatever
> Ubuntu LTS ships so we get useful disassembly for architecture
> extensions that postdate that.)

If we have a submodule, is it possible to have a local branch of that?  The
only thing I can see that would fix any of the above is to modify llvm to give
us a more usable interface.

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.

Thoughts?


r~