[lldb-dev] Rust support in LLDB, again

[Greg Clayton via lldb-dev]

> On Oct 20, 2019, at 5:30 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
> 
> On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton <clayborg at gmail.com <mailto: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.

FYI: we do have this with "frame variable". "frame variable foo->my_ptr[12]" will work for all child accesses, treating pointers as arrays, taking address of or dereferencing a pointer, etc. So we do have this functionality already with "frame variable". So give "frame variable" a try and see how things go.

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

It really depends on what you want to test. I am sure unit tests could be written that wouldn't require a compiler using yaml2obj if needed. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20191021/77e5dae9/attachment-0001.html>