<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Circling back around 4 months later...</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Any thoughts on this plan?</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Oct 29, 2015 at 10:11 AM, Dave Bartolomeo via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72">
<p class="MsoNormal"><b><span style="font-size:14.0pt">Proposed Design<u></u><u></u></span></b></p>
<p class="MsoNormal"><b>How Debug Info is Generated<u></u><u></u></b></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<u></u><u></u></b></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">DICompileUnit<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ e<i>xisting fields<u></u><u></u></i></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ CodeViewTypes : DICodeViewTypes<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">DICodeViewTypes<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ TypeRecords : MDString[]<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ UDTSymbols : DICodeViewUDT[]<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">DICodeViewUDT<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ Name : MDString<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ TypeIndex : uint32_t<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">DIVariable<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ <i>existing fields</i><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ TypeIndex : uint32_t<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">DISubprogram<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ <i>existing fields<u></u><u></u></i></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">+ TypeIndex : uint32_t<u></u><u></u></span></p>
<p class="MsoNormal"><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><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Name, an MDString with the name of the symbol as it should appear in the CodeView symbol record.<u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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.</p></div></blockquote></div></div></div>