[lldb-dev] Rust support in LLDB, again

Vadim Chugunov via lldb-dev lldb-dev at lists.llvm.org
Sun Oct 20 17:30:51 PDT 2019

On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton <clayborg at gmail.com> wrote:

> Yeah this is a tough tradeoff as this is what GDB does or at least did the
> last time I was working on it. In most debuggers, they make up their own
> internal type representation, and have a generic LALR recursive descent
> parser to evaluate single expression statements. This parser must work for
> multiple languages and problems arise when one language has a keyword or
> special operator that others don't have. In the old days, if you wanted to
> call a C++ function in the GDB expression parser you would need to put
> quotes around any qualified names that contained : characters because that
> had been overloaded by the expression parser before C++ to allow getting to
> a static variable in a file ("g_foo:main.c" or "main.c:g_foo"), So you had
> to type '"foo::bar"()' in your expression. The type system tries to avoid
> these issues by allowing each language to define the best functionality for
> each language.

Going a bit on a tangent here, but it isn't obvious that a debugger
expression evaluator needs to match full syntax and capabilities of the
source language.  I've been able to get quite a bit of mileage out of a
Python "expression evaluator" on top of a wrapper similar to lldb.value
<https://lldb.llvm.org/python_reference/lldb.value-class.html>.  Not
optimal by any stretch, but quite acceptable for baseline experience, IMO.

> One idea is to add rust support in its own TypeSystem and require a cmake
> option to manually enable its compilation. If the cmake flag isn't
> supplied, Rust is not compiled in by default. That way you can upstream it,
> people can try to enable it if any only if they download the rust compiler
> sources. Might be nice to have a rust compiler revision or hash that people
> can/should checkout that is documented in the checked out LLDB sources in
> the Rust type system README. This revision would be the last known good
> revision of the Rust compiler sources they should download in order to
> build the version of Rust that is in LLDB's sources. This way it would not
> break if we had a script in the Rust LLDB sources that knew how to checkout
> the right version of Rust and then users can manually enable Rust. Any rust
> enabled buildbots could ensure the right Rust sources are checked out.
> Maybe you could integrate this with the LLVM mono repo where Rust could be
> a module that can be added so when you add the
> '-DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;rust"' flag, it would know to
> build the rust bits needed for LLDB?

The Rust plugin is written in C++, so Rust compiler source won't be
necessary.  However a binary compiler release would be needed for testing.
It it certainly possible to make Rust support conditional on a cmake flag,
but would it be getting enough (or any) testing if not enabled by default?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20191020/b4f473d9/attachment.html>

More information about the lldb-dev mailing list