[cfe-dev] [RFC] New ClangDebuggerSupport Library

[Robinson, Paul via cfe-dev]

Adding assembler directives means the tests run only for those targets that use the integrated assembler?
I think a custom tool would be preferable, although as David said it should reuse LLVM's DIE classes if at all possible.
--paulr

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Adrian Prantl via cfe-dev
Sent: Friday, November 11, 2016 12:47 PM
To: Chris Bieneman
Cc: cfe-dev
Subject: Re: [cfe-dev] [RFC] New ClangDebuggerSupport Library


On Nov 11, 2016, at 11:19 AM, Chris Bieneman <cbieneman at apple.com<mailto:cbieneman at apple.com>> wrote:


On Nov 10, 2016, at 9:48 AM, Adrian Prantl via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:


On 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”.

I think this is an overall great idea.



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.

My understanding is that yaml2obj is a tool that allows us to generate (malformed) object files from a textual description so we can test tools like llvm-objdump. For a subset of DWARF, we already have a tool that translates DWARF from a textual description into an object file: the assembler. Currently it only supports the line table via .loc directives, but I imagine we could quite naturally add assembler directives for debug info DW_TAGs as well. Have you put any thought into this option?

The yaml<->obj tools allow generation of both structurally valid and malformed object files. Adding DWARF support would allow bit-for-bit identical round-tripping between YAML and DWARF which should make it easier to write and generate test cases that are human readable.

If the test is only concerned with the DWARF representation needing to use the assembler radically expands the surface area of LLVM code required to execute the tests. By contrast yaml2obj relies on very little of LLVM; the MachO side of yaml2obj only relies on libSupport and libObjectYAML, and we avoid complexity and code duplication by making the YAML format very explicit so the binary writer is simple.

Ok.


Also, the binary representation of DWARF in .s files is kinda not great for fabricating test cases from anything other than sources run through clang. Using YAML we could actually hand craft DWARF to drive testing.

That is why I said that we could add higher-level assembler directives to represent DWARF TAGs (similar to how we have .loc directives for describing the line table which are translated into the DWARF state machine by the assembler).

-- adrian


-Chris



-- adrian


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

_______________________________________________
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/2c5f0022/attachment.html>