On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton <clayb...@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?
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
