[cfe-dev] [RFC] New ClangDebuggerSupport Library

Wed Nov 9 18:29:22 PST 2016

> On Nov 9, 2016, at 6:21 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org <mailto:cfe-dev-bounces at lists.llvm.org>] On Behalf Of Chris
>> Bieneman via cfe-dev
>> Sent: Wednesday, November 09, 2016 2:26 PM
>> To: cfe-dev
>> Subject: [cfe-dev] [RFC] New ClangDebuggerSupport Library
>> 
>> Hello cfe-dev,
>> 
>> I would like to propose a new Clang library for implementing functionality
>> that is used by LLDB. I see this as the first step in a long process of
>> refactoring the language interfaces for LLDB.
>> 
>> The short-term goal is for this library is to be a place for us to rebuild
>> functionality that exists in LLDB today and relies heavily on the
>> implementation of Clang. As we rebuild the functionality we will build a
>> suite of testing tools in Clang that exercise this library and more
>> general Clang functionality in the same ways that LLDB will.
>> 
>> As bits of functionality become fully implemented and tested, we will
>> migrate LLDB to using the Clang implementations, allowing LLDB to remove
>> its own copies. This will provide the Clang community with a higher
>> confidence that changes in Clang do not break LLDB, and it will provide
>> LLDB with better test coverage of the Clang functionality.
>> 
>> The long-term goal of this library is to provide the implementation for
>> what could some day become a defined debugger<->frontend interface for
>> providing modularized (maybe even plugin-based) language debugging support
>> in LLDB. In the distant future I could see us being able to tell people
>> building new frontends that we have a defined interface they need to
>> implement for the debugger, and once implemented the debugger should “Just
>> Work”.
>> 
>> The first bit of functionality that I would like to build up into the
>> ClangDebuggerSupport library is materialization of Clang AST types from
>> DWARF. To support this development I intend to add a new tool in Clang
>> that reads DWARF types, generates a Clang AST, and prints the AST. I will
>> also add DWARF support to obj2yaml and yaml2obj, so we will be able to
>> write YAML LIT tests for the functionality.
> 
> I am not familiar with obj2yaml and yaml2obj, and I'm not finding any real
> documentation for them on the website.  But I can guess something about 
> them, and if I'm guessing anywhere close, having them understand DWARF 
> seems like a useful testing tool for debug info, independent of all the 
> rest of your proposal.

obj2yaml and yaml2obj are testing tools in LLVM used for testing binary files. I agree having DWARF support would improve testability for DWARF all across LLVM & Clang.

> 
> Would you be using LLVM's existing DWARF reader? Or replacing it with
> something from LLDB?  Adding a DWARF reader to Clang doesn't seem like
> the right choice, the object-file details really belong to LLVM.

Greg Clayton is working to move LLDB to using LLVM’s DWARF reader, so we would use LLVM’s reader in the Clang APIs as well. Part of why I’m proposing this be in a new library is so that Clang itself doesn’t need to pull in the DWARF reader from LLVM, but we won’t be adding any dependencies from Clang on LLDB.

> 
> To achieve your longer-term goal, LLDB would need to be completely
> isolated from AST and have no "native" understanding of the format.
> And yet, a library capable of evaluating a source-language expression 
> would need to be able to call back into the debugger in order to read
> and write process memory.  An interesting design challenge for sure.

I’ve been talking with Lang Hames about ways to abstract the remote JIT APIs to support this end goal. Hopefully we won’t need the language support library to have any access to the remote process. That said, this is all just my pipe dream at the moment.

-Chris

> --paulr
> 
>> 
>> If people are in favor of this general approach I’ll begin working in this
>> direction, and I’ll probably add the new library sometime next month.
>> 
>> Thoughts?
>> -Chris
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161109/179273f3/attachment.html>