[cfe-dev] [RFC] New ClangDebuggerSupport Library

David Blaikie via cfe-dev cfe-dev at lists.llvm.org
Fri Nov 11 09:20:41 PST 2016


On Fri, Nov 11, 2016 at 9:08 AM Reid Kleckner <rnk at google.com> wrote:

> On Fri, Nov 11, 2016 at 8:13 AM, David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> My knee-jerk reaction is that this could just as well live in LLDB if
> there are no other users - though Keno points out he could use it in Julia,
> so that seems like potentially sufficient interest to demonstrate that it
> might be a reasonable/reusable abstraction.
>
>
> I think this functionality should live in the clang codebase. The AST has
> a surprising number of invariants that are easy to violate. Right now LLDB
> is super tightly coupled to clang because it has to carefully learn and
> satisfy those invariants.
>

I'm not sure having it in the Clang codebase is going to make that much/any
easier to satisfy, it may shift the burden to the Clang project/developers
which is why I wonder whether it's a cost worth adding to the Clang
project/gating Clang changes on. If it's a service Clang (as a project)
thinks is worth vending to users, sure enough.


> The approach taken in LLDB is to essentially "deserialize" DWARF into
> ASTs. If we consider DWARF to be a stable serialization of the AST,
>

I wouldn't really think of it that way - for one thing, there's lots of
DWARF generated by things other than Clang (even for C++), so I don't see
the symmetry quite as much here.


> then the reading logic should live near the writing logic, which is
> currently in clang/lib/CodeGen/CGDebugInfo.cpp.
>

Just my 2c.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161111/bf65704e/attachment.html>


More information about the cfe-dev mailing list