[lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

>
> > 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.

A stable ABI for dynamically-loadable language plugins would be the best,
of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20191001/47e701ab/attachment-0001.html>