On Sat, Sep 12, 2020 at 5:52 AM Richard Henderson < richard.hender...@linaro.org> 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