qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: qemu disassembler status
Date: Fri, 11 Sep 2020 14:50:42 -0700	[thread overview]
Message-ID: <bb48e978-71e3-8ea8-44da-36c7d540ec1b@linaro.org> (raw)
In-Reply-To: <CAFEAcA8yfPdJLmek=+1VOWY4DQGP0yhmbtTiARw+qMuENKet+w@mail.gmail.com>

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~


       reply	other threads:[~2020-09-11 21:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFEAcA8yfPdJLmek=+1VOWY4DQGP0yhmbtTiARw+qMuENKet+w@mail.gmail.com>
2020-09-11 21:50 ` Richard Henderson [this message]
2020-09-11 22:36   ` qemu disassembler status 罗勇刚(Yonggang Luo)
2020-09-12  7:03   ` Thomas Huth
2020-09-12 10:17     ` 罗勇刚(Yonggang Luo)
2020-09-14  0:26     ` Richard Henderson
2020-09-14 11:29   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb48e978-71e3-8ea8-44da-36c7d540ec1b@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).