On Sat, Sep 12, 2020 at 3:04 PM Thomas Huth <th...@redhat.com> wrote:
> 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?
>
less is more, enforce people to add such stull to capstone is a good idea,
unless there is a
better altrenative than capstone
>
> Thomas
>
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
