[cfe-dev] [RFC] New ClangDebuggerSupport Library

[Robinson, Paul via cfe-dev]

(re-adding cfe-dev)

From: Robinson, Paul
Sent: Friday, November 11, 2016 8:53 AM
To: 'David Blaikie'; Chris Bieneman
Subject: RE: [cfe-dev] [RFC] New ClangDebuggerSupport Library

Maybe the DWARF-reader-writer-testing-tool bit should be split off to its own discussion, as several of us believe it has value independent of a ClangDebuggerSupport library.  Don't want to derail the latter while throwing out ideas for a textual DWARF representation.
--paulr

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via cfe-dev
Sent: Friday, November 11, 2016 8:14 AM
To: Chris Bieneman; cfe-dev
Subject: Re: [cfe-dev] [RFC] New ClangDebuggerSupport Library


On Wed, Nov 9, 2016 at 2:26 PM Chris Bieneman via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
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.

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?

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'll leave it up to Richard or others to weigh in on whether the ongoing cost to the Clang project would be worth the benefit to these users/use cases.

Beyond that - as for testing infrastructure. I'd like to make sure we only have one piece of code for generating DWARF, as we are trying to have one piece of code for reading it (& perhaps in some far off future - we could have one piece of code that does both, to some degree - at least some more shared information about the size/representation of forms, etc) - so however we're generating DWARF, it'd be good if that used the APIs in llvm's lib/CodeGen/AsmPrinter (potentially refactored out to some more general purpose location & generalized somewhat).

Not sure exactly what sort of syntax (how low level - presumably not raw bytes written in hex or anything) you're thinking of for writing DWARF - wonder if we could have a syntax that's nice enough to read that it's either the standard form llvm-dwarfdump could use, or at least a flag to enable it? (obviously dwarfdump wants to print things like byte offsets, etc - but a higher level symbolic rendering would probably be nice for many uses and be more likely what you'd want to write when writing a test case)

- Dave

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161111/02fab445/attachment.html>