<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 8:53 AM, Teresa Johnson via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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">tejohnson added a comment.<br>
<span class=""><br>
> !78 = !DICompositeType(tag: DW_TAG_class_type, name: "XMLPlatformUtils", scope: !17, file: !16, line: 104, size: 8, align: 8, elements: !79, identifier: "_ZTSN11xercesc_2_516XMLPlatformUtilsE")<br>
<br>
>  ...<br>
<br>
>  !93 = !DISubprogram(name: "Initialize", linkageName: "_ZN11xercesc_2_516XMLPlatformUtils10InitializeEPKcS2_PNS_12PanicHandlerEPNS_13MemoryManagerE", scope: !"_ZTSN11xercesc_2_516XMLPlatformUtilsE", file: !16, line: 204, type: !94, isLocal: false, isDefinition: false, scopeLine: 204, flags: DIFlagPublic | DIFlagPrototyped, isOptimized: true)<br>
<br>
<br>
</span>Correction, the DISubprogram that references the composite type (and was pulled in due to an import) is:<br>
!103 = distinct !DISubprogram(name: "alignPointerForNewBlockAllocation", linkageName: "_ZN11xercesc_2_516XMLPlatformUtils33alignPointerForNewBlockAllocationEm", scope: !"_ZTSN11xercesc_2_516XMLPlatformUtilsE", file: !104, line: 851, type: !105, isLocal: false, isDefinition: true, scopeLine: 852, flags: DIFlagPrototyped, isOptimized: true, declaration: !107, variables: !108)<br>
<span class=""><br>
> Why aren't these correlated by the metadata ID instead? I.e. !93 instead of !"_ZTSN11xercesc_2_516XMLPlatformUtilsE" in the DISubprogram scope? Then no TypeIdentifierMap would be needed.<br>
<br>
><br>
<br>
</span><span class="">> In any case, I added some handling for this, so that we detect and map in retained types onto the new DICompileUnit if they correspond to a DISubprogram that is being mapped in. However, I just hit another similar issue. In this case, the retained type DICompositeType identifier is the base type of a DIDerivedType needed by a DISubprogram that was mapped in. E.g.:<br>
<br>
><br>
<br>
> !3 = !DICompositeType(tag: DW_TAG_enumeration_type, name: "PanicReasons", scope: !"_ZTSN11xercesc_2_512PanicHandlerE", file: !4, line: 116, size: 32, align: 32, elements: !5, identifier: "_ZTSN11xercesc_2_512PanicHandler12PanicReasonsE")<br>
<br>
>  ...<br>
<br>
>  !107 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !"_ZTSN11xercesc_2_512PanicHandler12PanicReasonsE")<br>
<br>
><br>
<br>
> where the DIDerivedType is the DISubroutineType for a DISubprogram that was mapped in. I'll need to extend my handling a bit to get this case. Same question here though, why doesn't it just use "baseType: !3"?<br>
<br>
<br>
</span>It turns out the second problem was caused by the fix for the first. The subprogram that referenced the DIDerivedType !107 was only mapped in because it is in the list of elements for the DICompositeType !78 that was the scope for the function needed due to importing. So the set of what debug metadata needs to be imported keeps exploding as the problem is addressed.<br>
<br>
Is there any way to avoid this? Does the complete DICompositeType !78 need to be recreated in the importing module? It isn't clear to me which debug type metadata needs to be fully recreated in the importing module, I know the original premise behind this patch was that it was sufficient for it to exist in the original module. But getOrCreateSubprogramDIE wants to get the ContextDIE for the subprogram.<br></blockquote><div><br></div><div>Subprogram DIEs will need the right context for the DWARF to be correct/valid, so some amount of DWARF is going to need to be cloned into any module where the subprogram/function is emitted (even if it is only emitted inline)<br><br>Essentially, the minimal DWARF you would need for a subprogram that might be a member of a type would be:<br><br>Declaration of outer type<br>  Declaration of member function<br>Definition of member function (referencing the declaration)<br><br>So you still need to clone the metadata declaration to match the definition, and the scope chains of both declaration and definition (but I don't think we put the definition inside any scopes if it's an implicit definition of a member (that's vague wording, I can be more specific)), but you can avoid importing lots of stuff if you demote any definitions of user defined types (structs, classes, enums, etc) to declarations.<br><br>So long as the types stick around as definitions somewhere.<br><br>The DWARF produced here will look similar to other things we produce with -fno-standalone-debug (this is the default on non-Apple platforms) - types in DWARF that are only a declaration and have arbitrary subsets of members, but there will be an authoritative definition somewhere in the LTO'd program (wherever the types were drawn from). This shouldn't hit the problematic cases Apple has on their platform that necessitated them turning to -fstandalone-debug. It probably won't even hit the LLDB bugs that are exposed by -fno-standalone-debug either (because the debug info will be standalone in the destination module before we import anything, so we won't create the weird situations that LLDB fails on)<br><br>- David</div></div></div></div>