[lldb-dev] Rust support in LLDB, again

Jonas Devlieghere via lldb-dev lldb-dev at lists.llvm.org
Mon Sep 30 09:28:34 PDT 2019

Hi Vadim,

On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev
<lldb-dev at 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?

> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list