<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 31, 2015 at 3:07 PM, Zachary Turner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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"><div dir="ltr"><div>Definitely having someone who knows both formats well would be an advantage. Dave B might be in the best position to do this, so hopefully he can provide a couple more examples of areas where he has trouble expressing CV information entirely in the backend. <br></div><div><br></div>Regardless of what everyone ends up deciding on with regards to the front-end / back-discussion, I want to suggest separating the work into separate pieces that can go in independently of each other.<div><br></div><div>For example, the proposed LLVMCodeView library, which simply reads and writes raw CV records, seems to be orthogonal to this discussion and could be submitted independently.</div></div></blockquote><div><br></div><div>I haven't looked at the patch in general, but that sounds quite plausible - unit tests or what-have-you that demonstrate the expected behavior regardless of wehre it ultimately ends up being used from (LLVM, Clang, or both)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 31, 2015 at 12:04 PM Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The details of the mangling would be ABI dependent not debug-info-format dependent. Metadata already allows conveying a mangled name into LLVM, as David Blaikie
mentioned, so that's not really an issue. The frontend knows how to construct the mangled name, the backend knows where the mangled name goes in the final debug info. It's a pretty reasonable separation of concerns.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I didn't see anything in this quickie overview of CodeView that wouldn't be expressible in DWARF, so there's nothing (yet) persuasive to suggest metadata should
be format-aware. It would be worthwhile for somebody knowledgeable in one format to take a good detailed look at the other, just to make sure; please provide a link to the detailed CodeView description when it becomes available.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regarding source-language awareness of the debug-info generator, that's really not a concern (and I say this as someone who once helped add DWARF emission of
COBOL-specific entries to a compiler backend that was not entirely clear how to spell COBOL). You need an API that is able to specify the constructs used by the language, and the rest of it is just processing those record types the way they're supposed to
be. The backend is not doing any language-semantic analysis of the info, it's just doing what it's told.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Abstractly, the exercise of generalizing LLVM metadata to be able to support more than one debug-info format feels like a good thing. Metadata used to be more
closely tied to DWARF (e.g., used DWARF tag codes directly in the metadata nodes to identify things) but it has been evolving away from that to a class hierarchy that is not so explicitly DWARF-ish. Handling CodeView would encourage that direction, rather
than being a more fundamental shift.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="150bff0e839fe772_msg-f:1516574627207740297__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>David Blaikie via cfe-dev<br>
<b>Sent:</b> Friday, October 30, 2015 8:07 PM<br>
<b>To:</b> Dave Bartolomeo<br>
<b>Cc:</b> llvm-dev; Clang Dev<br>
<b>Subject:</b> Re: [cfe-dev] [llvm-dev] RFC: CodeView debug info emission in Clang/LLVM<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<p>Brief answer, but can go into detail later:<u></u><u></u></p>
<p>If this is the right idea, lets do it for dwarf too & generalize the support to work for both. It's certainly something we've considered, to save all the complexity of representing essentially static data in an intermediate form.<u></u><u></u></p>
<p>That said, given some of the stuff we have for lto, for example (deallocating/merging types etc) I'm not sure that's obviously the right strategy.<u></u><u></u></p>
<p>Mangled names for types don't seem like a hugely difficult feature. We already support mangled names for function debug info in dwarf. We already have the mangled name of a type in the metadata, it could be used for codeview emission.<u></u><u></u></p>
<p>It might be worth talking more & considering what other language features codeview uses that we haven't already plumbed through for dwarf (& dwarf based debuggers use dwarf for expression evaluation too, fwiw)<u></u><u></u></p>
<div>
<p class="MsoNormal">On Oct 30, 2015 5:12 PM, "Dave Bartolomeo via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Saleem Abdulrasool [mailto:<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>]
<br>
<b>Sent:</b> Thursday, October 29, 2015 10:02 PM<br>
<b>To:</b> Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>><br>
<b>Cc:</b> Dave Bartolomeo <<a href="mailto:Dave.Bartolomeo@microsoft.com" target="_blank">Dave.Bartolomeo@microsoft.com</a>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>;
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] RFC: CodeView debug info emission in Clang/LLVM</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Thu, Oct 29, 2015 at 2:08 PM, Adrian Prantl via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
> On Oct 29, 2015, at 10:11 AM, Dave Bartolomeo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Proposed Design<br>
> How Debug Info is Generated<br>
> The CodeView type records for a compilation unit will be generated by the front-end for the source language (Clang, in the case of C and C++). The front-end has access to the full type system and AST of the language, which is necessary to generate accurate
debug type info. The type records will be represented as metadata in the LLVM IR, similar to how DWARF debug info is represented. I’ll cover the actual representation in a bit more detail below.<br>
> The LLVM back-end will be responsible for emitting the CodeView type records from the IR into the output .obj file. Since the type records will already be in the correct format, this is essentially just a copy. No inspection of the type records is necessary
within LLVM. The back-end will also be responsible for generating CodeView symbol records, line numbers, and source file info for any functions and data defined in the compilation unit. The back-end is the logical place to do this because only the back-end
knows the code addresses, data addresses, and stack frame layouts.<br>
<br>
Thanks for proposing this.<br>
<br>
How different are the type records from the type information we currently have in LLVM's DIType hierarchy? Would it be feasible to move the logic for generating type records from LLVM metadata into the backend? This way a frontend could be agnostic about the
debug information format.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I think that this really is the path we want to follow. If the current metadata we emit is insufficient, we should augment it with additional information sufficient to generate
the necessary data in the backend. The same annotations would then be able able to generate one OR both debug info formats.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">[dB] I considered that approach, but I see a few reasons why I don’t think making the debug
metadata format agnostic would work out very well. To ensure that the backed can generate both debug formats by itself, we need to make the metadata contain enough information from the original AST for the format-specific code in the backend to generate the
debug info. I believe that in practice, we’d wind up having to encode a significant portion of the AST (for decls of types and members, at least) into metadata, because debug type info, at least in CodeView, strives for pretty close fidelity with the declarations
and types in the original source language. The CodeView debug type info is used by the VS debugger to parse and evaluate C++ expressions while debugging. We currently have a bunch of limitations in our debugger’s expression evaluation due to information missing
from the debug type info, and we’ll probably attempt to preserve even more of that information going forward. There’s not much information from the AST that we can ignore if we want to reach that goal. Of course, we could just accept that we need the majority
of the AST for type and function declarations in the debug metadata, and do that work in order to avoid having the frontend know about debug info formats, but that just means that now the backend code that generates the debug info has to know about all of
the source language-specific constructs that it’s reading when creating the debug info. I think I’d rather have Clang have to understand the language-specific parts of multiple debug info formats than have LLVM understand language-specific metadata.</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As an example, the CodeView definition of a user-defined type requires both the mangled name
of the type and the non-mangled “display name” of the type. Both of these require a fair bit of information from the AST to generate. For the mangled name in particular, there’s already code in Clang that generates this. If we want the backend to do this instead,
we have to stuff a bunch of AST info into metadata, and then figure out how to share the name mangling code between Clang (where it operates on actual ASTs) and LLVM (where it would operate on metadata). If, instead, we have Clang compute the mangled name
and display name and pass those names in the metadata, we’re not being particularly format-agnostic in Clang, and if the current compilation is only generating DWARF, we didn’t really need to compute or store those potentially large strings for every type
anyway.</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Whether Clang is format-agnostic or not, there will have to be some component that converts
from something format-agnostic (either ASTs or metadata) to DWARF, and some component that converts from ASTs or metadata to CodeView. You can put those two components in Clang and accept that Clang won’t be format-agnostic. Or, you can put those two components
in LLVM, which leaves Clang as format-agnostic but requires that LLVM be more source language-aware. It also requires a third component to translate ASTs into metadata to pass to LLVM. Letting Clang worry about two different debug type info formats seems preferable
to writing additional code and making an LLVM component understand more about the source language.</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Is there another approach I haven’t thought of that would let us wind up with a cleaner solution?
I’ve only been working with the Clang and LLVM debug info code for a few months, so my knowledge of the existing design is far from complete.</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Note that for the rest of debug info (line numbers, source files, stack layouts, etc.), I don’t
think the frontend should have to worry about the debug info format, and the current design for those pieces is just fine. It’s only the type info that I think is source language-specific enough to justify computing it in the frontend.</span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></i></b><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">-- adrian<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7cDave.Bartolomeo%40microsoft.com%7cd240c2d59d2a4a17baf508d2e0e74c79%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Fz6kMmt9LpwG7SvGYKLA4g3%2fYaBWp0AAhFsJKkZQARE%3d" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div>
<p class="MsoNormal">Saleem Abdulrasool<br>
compnerd (at) compnerd (dot) org<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</div>
</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>