> On Oct 20, 2019, at 5:30 PM, Vadim Chugunov <vadi...@gmail.com> wrote: > > On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton <clayb...@gmail.com > <mailto: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.
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.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
