<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 10, 2016 at 9:48 AM, Adrian Prantl via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 9, 2016, at 2:26 PM, Chris Bieneman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello cfe-dev,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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”.<br>
<br>
</span>I think this is an overall great idea.<br>
<span class=""><br>
><br>
> 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.<br>
<br>
</span>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.</blockquote><div><br></div><div>Small correction / hostorical anecdote:</div><div><br></div><div>That is true for the COFF and Mach-O formats of yaml2obj. For historical reasons though, the ELF part of yaml2obj is different and makes it quite difficult actually to create malformed object files (e.g. wild offsets or section numbers). The design goal for the ELF part of yaml2obj was to serve as a testing tool for LLD: you would take an interesting object file, run obj2yaml, then pare it down in your editor and use that as a test input by yaml2obj'ing it in the test (so you had to have reasonable safety guarantees when editing the YAML that you wouldn't create a corrupt object file).</div><div><br></div><div>This was used extensively for testing the Atom ELF LLD, but now that it is gone, there are very few users of the ELF yaml2obj (early in lld/ELF's development it was decided that .s files would be used instead of yaml2obj). Arguably, it might be better to change the ELF part of yaml2obj to be consistent with the other two formats now that its original design purpose is mostly gone. Or maybe just delete it.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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?<br>
<br>
-- adrian<br>
<div class="HOEnZb"><div class="h5">><br>
> 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.<br>
><br>
> Thoughts?<br>
> -Chris<br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>