Hi Vadim, On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev <lldb-dev@lists.llvm.org> wrote: > > Hi, > Last year there was an effort led by Tom Tromey to add Rust language support > into LLDB. He had implemented a fairly complete language plugin, however it > was not accepted into mainline because of supportability concerns. I guess > these concerns had some merit, because this change did not survive even in > Rust's private branch due to the difficulty of rebasing on top of LLVM 9.
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. > I am wondering if there's a more limited version of this, that can be merged > into mainline: > In terms of its memory model, Rust is not that far off from C++, so treating > Rust types is if they were C++ types basically works. There is only one > major problem: currently LLDB cannot deal with tagged unions, which Rust code > uses quite heavily. When such a type is encountered, LLDB just emits an > empty struct, which makes it impossible to examine the contents. > > 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. > What would y'all say? The people that actually work on this code should answer this, but personally I don't have strong objections to this. That said, of course I would prefer to have a (maintained) language plugin instead. PS: Are there other changes that live downstream that are not Rust specific and would benefit upstream LLDB and would potentially improve Rust debugging? Jonas > > _______________________________________________ > 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
