<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 17, 2019, at 11:42 PM, Vadim Chugunov <<a href="mailto:vadimcn@gmail.com" class="">vadimcn@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Greg,</div><div class=""><br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="">So if Rust doesn't use clang in its compiler</div><div class="">- 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</div><div class="">- write a native Rust expression parser which hopefully uses your Rust compiler sources to evaluate and run your expression</div></div></blockquote><div class=""><br class=""></div><div class="">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).<br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""></div><div class="">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?</div></div></blockquote><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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. </div></div></div></div></blockquote><div><br class=""></div><div>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. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> 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. <br class=""></div><div class="">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?<br class=""></div></div></div></div></blockquote><div><br class=""></div>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. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="">Let us know about which approach sounds better to the Rust community and we can proceed from there!</div></div></blockquote><div class=""><br class=""></div><div class="">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...<br class=""></div></div></div></div></blockquote><div><br class=""></div>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?</div><div><br class=""></div><div>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?</div><div><br class=""></div><div>Greg</div></body></html>