no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as well. Given that I think everyone mostly agrees that unifying on one DWARF parser is a good idea in principle, this would mean no functional change from LLDB's point of view, it would just continue to do exactly what it does regarding parsing C++ expressions and converting these into types that clang understands.
It will probably be useful someday to have an expression parser and language specific type system, but when that comes I don't think we'd want anything radically different than what LLDB already has. On Tue, Jun 26, 2018 at 12:26 PM Jim Ingham <jing...@apple.com> wrote: > Just to be clear, by "no clang integration" do you mean "no expression > parser" or do you mean something more radical? For instance, adding a > TypeSystem and its DWARF parser for C family languages that uses a > different underlying representation than Clang AST's to store the results > would be a lot of work that wouldn't be terribly interesting to lldb. I > don't think that's what you meant, but wanted to be sure. > > Jim > > > On Jun 26, 2018, at 11:58 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi all, > > > > We have been thinking internally about a lightweight llvm-based > ptracer. To address one question up front: the primary way in which this > differs from LLDB is that it targets a more narrow use case -- there is no > scripting support, no clang integration, no dynamic extensibility, no > support for running jitted code in the target, and no user interface. We > have several use cases internally that call for varying levels of > functionality from such a utility, and being able to use as little as > possible of the library as is necessary for the given task is important for > the scale in which we wish to use it. > > > > We are still in early discussions and planning, but I think this would > be a good addition to the LLVM upstream. Since we’re approaching this as a > set of small isolated components, my thinking is to work on this completely > upstream, directly under the llvm project (as opposed to making a separate > subproject), but I’m open to discussion if anyone feels differently. > > > > LLDB has solved a lot of the difficult problems needed for such a tool. > So in the spirit of code reuse, we think it’s worth trying componentize > LLDB by sinking pieces into LLVM and rebasing LLDB as well as these smaller > tools on top of these components, so that smaller tools can reduce code > duplication and contribute to the overall health of the code base. At the > same time we think that in doing so we can break things up into more > granular pieces, ultimately exposing a larger testing surface and enabling > us to create exhaustive tests, giving LLDB more fine grained testing of > important subsystems. > > > > A good example of this would be LLDB’s DWARF parsing code, which is more > featureful than LLVM’s but has kind of evolved in parallel. Sinking this > into LLVM would be one early target of such an effort, although over time > there would likely be more. > > > > Anyone have any thoughts / strong opinions on this proposal, or where > the code should live? Also, does anyone have any suggestions on things > they’d like to see come out of this? Whether it’s a specific new tool, new > functionality to an existing tool, an architectural or design change to > some existing tool or library, or something else entirely, all feedback and > ideas are welcome. > > > > Thanks, > > Zach > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
