> On Oct 17, 2019, at 11:42 PM, Vadim Chugunov <vadi...@gmail.com> wrote:
>
> Hi Greg,
>
> So if Rust doesn't use clang in its compiler
> - create a new TypeSystem for Rust that would convert DWARF into Rust AST
> types that are native to your Rust compiler that uses as much of the Rust
> compiler sources as possible
> - write a native Rust expression parser which hopefully uses your Rust
> compiler sources to evaluate and run your expression
>
> This already exists, but is proving difficult to maintain out-of-tree. (I
> wish that people who modify plugin-related APIs would spend a few minutes
> documenting what each of those methods is supposed to do, so plugin
> maintainers wouldn't need to reverse-engineer this info! /rant).
>
> So the right answer depends on what the Rust community wants. Is the language
> changing rapidly where the debugger must be in sync to take advantage and use
> the latest language features? Or is it stable?
>
> Debug info is mostly stable, but over time there will be changes, of course.
> For example, at some point we'll want to change the symbol mangling scheme.
>
> The other nice things about creating a new TypeSystem, is that it is a plugin
> and you don't need to compile it in. cmake can be taught to conditionally
> compile in your type system if you want it. It would also allow you to have
> more than one Rust type system if needed for different Rust language versions
> that each could be exclusively compiled in. Having your sources be in a new
> TypeSystem plug-in ensure easy merging when it comes to different
> repositories.
>
> Understood. I just want to point out that implementing a complete type
> system plugin just to support one or two type kinds incompatible with C++ is
> a pretty big burden on language implementors.
It definitely is, but I believe that good debugging tools helps people adopt
your language more quickly and if people invested a bit more into the debugging
experience we would have more languages to play with.
> If LLDB had a default "type system" geared towards representing types
> expressible in DWARF, not just those found in the C family, it would be
> usable with other languages without any custom work, at least until one
> starts getting into fancy features like REPL.
> It might also serve as an abstraction layer for supporting different debug
> info formats. As I understand, right now, in order to support MS PDB, we'd
> need to implement a custom parser for it in addition to the DWARF one?
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.
So one route would be to allow your language to use an internal type system
that isn't based on any compiler back end. But that is going to be just as much
work as making a new Rust type system and more problematic to maintain as other
languages jump on board.
>
> Let us know about which approach sounds better to the Rust community and we
> can proceed from there!
>
> I guess we'd prefer to upstream the Rust plugin. But I'm not sure how keep
> it from breaking without requiring all LLVM devs to install a Rust compiler...
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?
I am happy to help in any way I can. Are the rust compiler sources setup in a
way that the debugger could end up using the Rust AST and other data structures
when converting types from DWARF? Could the rust compiler be used to evaluate
expressions with the converted DWARF to Rust AST in a Rust LLDB type system?
Greg_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
