<div dir="ltr">Hi All,<div><br></div><div>Reid, Dave and I have chatted about this quite a bit and I think we have a way forward that gets us in a direction we'd like to go, offers some potential performance benefits for existing dwarf users, and maintains some compatibility while transitions are happening. We're currently writing up a proposal and will send it out for RFC shortly.</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 10, 2016 at 10:51 AM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">It is certainly *possible* to use the existing DIType hierarchy to generate CodeView, but I don't believe it is useful. We would have to make the DI metadata into the union of DWARF and CodeView, and it would be horrible. Here is an incomplete list of things that would be awkward:</div><div class="gmail_quote"><br></div><div class="gmail_quote">- Member pointer inheritance models. Not all pointers to members are the same size.</div><div class="gmail_quote">- Describing locations of virtual bases in vbtables. I'm not sure how to get from DW_TAG_inheritance data to "offset of vbptr from vfptr of complete class".</div><div class="gmail_quote">- Describing 'this' adjustments performed in virtual method prologues.</div><div class="gmail_quote">- New virtuality types to indicate "introducing" virtual methods.<br></div><div class="gmail_quote">- New flags on everything, see CodeView.h for more info.</div><div class="gmail_quote"><br></div><div class="gmail_quote">If you need more visibility into what's different, consider this C++ source:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">struct A { </div><div class="gmail_quote"> virtual void f() {}</div><div class="gmail_quote"> int a;</div><div class="gmail_quote">};</div><div class="gmail_quote">struct B : virtual A {</div><div class="gmail_quote"> virtual void f() {}</div><div class="gmail_quote"> virtual void g() {}</div><div class="gmail_quote"> int b;</div><div class="gmail_quote">};</div><div class="gmail_quote">struct C : virtual A {</div><div class="gmail_quote"> virtual void f() {}</div><div class="gmail_quote"> virtual void h() {}</div><div class="gmail_quote"> int c;</div><div class="gmail_quote">};</div><div class="gmail_quote">struct D : B, C {</div><div class="gmail_quote"> virtual void f() {}</div><div class="gmail_quote"> virtual void g() {}</div><div class="gmail_quote"> virtual void h() {}</div><div class="gmail_quote"> int d;</div><div class="gmail_quote">};</div><div class="gmail_quote">D d;</div><div class="gmail_quote">auto mp = &D::f;</div><div><br></div><div>Compare the metadata that clang generates with the dump of the codeview that MSVC generates, and decide for yourself if the representations are a good match:</div><div>$ clang -cc1 -std=c++11 -emit-llvm -debug-info-kind=limited t.cpp -o - -triple x86_64-linux -o t.ll</div><div>LLVM IR: <a href="https://ghostbin.com/paste/dpqo8" target="_blank">https://ghostbin.com/paste/dpqo8</a></div><div>$ cl -c t.cpp -Z7 && llvm-readobj -codeview t.obj</div><div>Dump of MSVC CodeView: <a href="https://ghostbin.com/paste/92ya3" target="_blank">https://ghostbin.com/paste/92ya3</a></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Sure, yes, it is *possible* to write a converter from one to the other, but why is it necessary? What use case does it enable?</div><div class="gmail_quote"><br></div><div class="gmail_quote">You might think it would allow non-Clang frontends to avoid having separate type info emitters, but in practice it won't, because these frontends will need to be augmented to pass down all kinds of CV-specific junk.</div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Mar 8, 2016 at 4:39 AM, Aboud, Amjad <span dir="ltr"><<a href="mailto:amjad.aboud@intel.com" target="_blank">amjad.aboud@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I said it before and I am saying it again, I do not think that this proposal is needed to support Codeview.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Why cannot Codegen make use of current DIType metadata to represent the codeview types?<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Why cannot “DW_TAG_typedef” be used to generate the “DICodeViewUDT” symbol?<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>3.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Why do we need the TypeIndex?<u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">DISubprogram and DIVariable simply point to the DIType metadata, instead of having an index into an array where these DIType
are stored?!<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>4.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Why the “TypeRecords” are of type MDString? Are they the source name of the type?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I believe that current Debug Info metadata contains all information needed to create the codeview information in codegen.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thus, I do not see a need to either modify Clang or even modify the LLVM IR.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Please, if you have a concrete case where you think we have lost information needed for codeview between Clang and Codegen, tell us about it and I will be happy
to help you figure out how to retrieve this information from current DI metadata.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Amjad<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-2034724051215543896_1418482314__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></p>
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-color:rgb(225,225,225);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><a name="m_-2034724051215543896_1418482314______replyseparator"></a><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>David Blaikie via llvm-dev<br>
<b>Sent:</b> Thursday, March 03, 2016 20:26<br>
<b>To:</b> Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>><br>
<b>Cc:</b> <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] [cfe-dev] RFC: CodeView debug info emission in Clang/LLVM<u></u><u></u></span></p>
</div>
</div><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends
(& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM because type info and other DWARF are described by similar/the same constructs (DIEs, abbrevs, etc) - but it seems like that's
not the case for PDB, so there might not be any code to share between LLVM's CodeView needs and the type info construction - then it's just a matter of whether pushing that library down into LLVM for other frontends to use would be good, which it probably
will be at some point, so if it goes into Clang I'd at least try to keep it pretty well separated)<br>
<br>
Potentially that consistency could be created by going the other way - replace DITypeRef with an int, then have the retained types list be the int->type mapping. Skipping the mangled names. (& skip the retained types list for CV/PDB)<br>
<br>
- Dave<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Mar 2, 2016 at 5:19 PM, Reid Kleckner 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>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">Circling back around 4 months later...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I now believe that we should just let the frontend generate CV type info. It's really not worth the hassle to try to have a common representation. Enough C++ ABI-specific information leaks into the format that it's really better to avoid
trying to create a union of DWARF and CV type info in LLVM DI metadata. We were able to reuse all the other non-type DI metadata, such as location info and scope info, to emit inline line tables and variable locations, so I think we did OK on reusing the existing
infrastructure. Compromising at not reusing the type representation seems OK.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I haven't come up with any ideas better than the design that Dave Bartolomeo outlined below, so I think we should go ahead with that. One thing I considered was extending DITypeRef to be a union between MDString*, DIType*, and a type index,
but I think that's too invasive. I also don't want to make a whole DIType heap allocation just to wrap a 32-bit type index, so I'm in favor of putting the indices into DISubprogram and DIVariable.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Any thoughts on this plan?<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">On Thu, Oct 29, 2015 at 10:11 AM, 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>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><b><span style="font-size:14pt">Proposed Design</span></b><u></u><u></u></p>
<p class="MsoNormal"><b>How Debug Info is Generated</b><u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>Representation of CodeView in LLVM IR</b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">DICompileUnit</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ e<i>xisting fields</i></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ CodeViewTypes : DICodeViewTypes</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">DICodeViewTypes</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ TypeRecords : MDString[]</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ UDTSymbols : DICodeViewUDT[]</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">DICodeViewUDT</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ Name : MDString</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ TypeIndex : uint32_t</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">DIVariable</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+
<i>existing fields</i></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ TypeIndex : uint32_t</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">DISubprogram</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+
<i>existing fields</i></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:'Courier New'">+ TypeIndex : uint32_t</span><u></u><u></u></p>
<p class="MsoNormal">The existing DICompileUnit node will have a new operand named CodeViewTypes, which points to the new DICodeViewTypes node that describes the CodeView type information for the compilation
unit. <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The DICodeViewTypes node contains two operands:
<u></u><u></u></p>
<p>-<span style="font-size:7pt"> </span>TypeRecords, an array of MDStrings containing the actual CodeView type records for the compilation unit, sorted in ascending order of type index.<u></u><u></u></p>
<p>-<span style="font-size:7pt"> </span>UDTSymbols, and array of DICodeViewUDT nodes describing the user-defined types (class/struct/union/enum) for which CodeView symbol records will need to be emitted by the back-end.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The DICodeViewUDT node contains two operands:<u></u><u></u></p>
<p>-<span style="font-size:7pt"> </span>Name, an MDString with the name of the symbol as it should appear in the CodeView symbol record.<u></u><u></u></p>
<p>-<span style="font-size:7pt"> </span>TypeIndex, a uint32_t holding the CodeView type index of the type record for the user-defined type’s definition.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The DICodeViewUDT nodes are necessary because they are generally the only references to the definition of the user-defined type. Other uses of that type refer to the forward declaration
record for the type, and without a reference to the definition of the type, the linker will discard the definition record when it merges the type information into the PDB.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">To specify the CodeView type for a variable or function, the DIVariable and DISubprogram nodes will have an additional TypeIndex operand containing the type index of the type record
for that variable or function’s type. This operand will be set to zero when CodeView debug info is not enabled.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The above representation essentially extends the existing DWARF-focused debug metadata to also include CodeView info. This was the least invasive way I found to add CodeView support,
but it may not be the right architectural decision. It would also be possible to have the CodeView metadata entirely separate from the DWARF metadata. This would reduce the size of the IR when only one form of debug information was being emitted, which is
presumably the common case. However, I expect it would complicate the scenario where both DWARF and CodeView are being emitted; for example, would having two dbg.declare intrinsics for a single local variable confuse existing consumers of LLVM IR? I’m hoping
someone more familiar with the existing debug info architecture can provide some guidance here if there’s a better way of doing this.<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p><span>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></span></div>
</blockquote></div><br></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>