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
