On Sat, Sep 12, 2020 at 5:52 AM Richard Henderson <
[email protected]> 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.
>
>
> >> 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.
>
I agree with this, use git submodule or nothing, to maintain less things
and have consistence experience
>
> Thoughts?
>
>
> r~
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
