> On Oct 1, 2019, at 11:54 AM, Vadim Chugunov via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > Unless my memory is failing me, I don't think we ever explicitly > > rejected Rust's language plugin. We removed a few other language > > plugins (Go, Java) that were not maintained and were becoming an > > increasing burden on the community. At the same time we agreed that we > > didn't want to make the same mistake again. Some of the things that > > come to mind are having a working implementation, testing, CI, etc. If > > the rust community can show that they're dedicated to maintaining Rust > > support in LLDB, I wouldn't expect a lot of resistance. I just bring > > this up because I don't want to discourage anyone from adding support > > for new languages to LLDB. > > Do you have any thoughts on how this support should look like? > > Realistically, though, I would expect this to go about as well as the > previous two attempts you've mentioned. :( > > >> My tentative proposal is to modify LLDB's DWARFASTParserClang to handle > >> DW_TAG_variant et al, and create a C++ approximation of these types, e.g. > >> as a polymorphic class, or just an untagged union. This would provide at > >> least a minimal level of functionality for Rust (and possibly other > >> languages) and be a much lesser maintenance burden on LLDB core team. > > I looked at the code in more detail, and unfortunately it looks like C++ AST > is not flexible enough to represent variants as polymorphic classes, so It'll > have to be just untagged unions. But I'd love to hear otherwise from people > more familiar with that code. > > > PS: Are there other changes that live downstream that are not Rust > > specific and would benefit upstream LLDB and would potentially improve > > Rust debugging? > > Nothing major I can think of. The rest of changes seem to be pretty > Rust-specific. > > My general feedback is that it would help a lot if LLDB were less C++- (and > in particular clang-) centric. For example, right now LLDB converts various > debug info formats directly into clang AST. As a result, other languages are > forced to re-implement debug info parsing from scratch and soon as they need > to customize anything that cannot be mapped to C/C++ concepts. There > probably needs to be some sort of language-agnostic layer that abstracts > debug info formats for use by language plugins. If this layer supported > DWARF spec in its entirety, I expect that most languages would need little to > no customization, at least until you get to implementing a REPL for that > language.
Swift has its own AST, and a separate DWARF->SwiftAST parsers, and an independent expression evaluator and runtime. Though the Swift support is in a separate repository, all the plugin code to handle an entirely non-C++ like language is also present in the llvm.org sources. That requires building a fair bit of the compiler into lldb - which may bring up license issues for Rust - but it is possible. > > A stable ABI for dynamically-loadable language plugins would be the best, of > course. The interface for language plugins is still evolving, as we move the clang (and swift) dependencies out of generic code and into the plugins (shout out to Alex for his persistence in this effort!!!). And I don't think the language plugins will ever be stable in the way the SB API's are. They rely on too many llvm constructs, and those are not guaranteed to be stable. In that sense lldb will be like developing with the rest of the llvm infrastructure. Stable enough in API form, and factored out well enough, that keeping up with external changes won't be too much of a pain, but still requiring recompiles. Jim > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
