<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 6:43 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Jan 26, 2016 at 4:05 PM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Jan 26, 2016 at 9:47 AM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.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 dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Jan 26, 2016 at 9:09 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.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 dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">tejohnson added a comment.<br>
<span><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><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>> 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></span><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></div></div></div></div></blockquote><div><br></div></span><div>Thanks, this is helpful.</div><div><br></div><div>Just talked to David Blaikie offline, he pointed me to the composite type declarations being marked with "flags: DIFlagFwdDecl" instead of having an element list. He pointed out that I need to follow the scope chains of the imported Subprogram definition and declaration all the way up but can make them declarations instead of importing all the member elements. And ditto for the types hanging off the imported subprogram.</div></div></div></div></blockquote><div><br></div></div></div><div>What about the vtableHolder? With my new changes I getting the following verification error:</div><div><br></div><div><div>unresolved type ref</div><div>!"_ZTSN11xercesc_2_57LocatorE"</div><div>!4554 = !DICompositeType(tag: DW_TAG_class_type, name: "ReaderMgr", scope: !985, file: !2308, line: 177, size: 640, align: 64, flags: DIFlagFwdDecl, vtableHolder: !"_ZTSN11xercesc_2_57LocatorE", identifier: "_ZTSN11xercesc_2_59ReaderMgrE")</div></div><div><br></div><div>I am following the scope chains and bringing in referenced type decls, do I need to do the same for the vtableHolder if it exists? Any others?</div></div></div></div></blockquote><div><br></div></div></div><div>No, I shouldn't think so - a declaration should be much simpler than that.<br><br>I'd suggest finding a type with a vtable holder - just make a small example:<br><br>struct foo {<br>  virtual ~foo() {}<br>} f;<br><br>& look at the type description in metadata - I assume it'll have a vtableHolder.<br><br>Now try a declaration instead:<br><br>struct foo {<br>  virtual ~foo() {}<br>} *f;<br><br>Should produce just the declaration of 'foo', and probably won't have a vtableHolder. You should probably have/not have whatever the declaration of 'foo' has. Which should be nothing but name and the decl flag, really (& scope). It probably doesn't need anything else. (I guess some parts of the debug info emission might need/expect file/line, but it shouldn't really be needed)<br></div></div></div></div></blockquote><div><br></div><div>Ok, thanks. Confirmed via similar example comparison that template params also should be dropped when demoting to declaration. The patch seems to be working now for xalancbmk, but needs some cleanup before I send it out.</div><div><br></div><div>Teresa</div><div><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"><div><br>- Dave</div><span class=""><div> </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"><div><br></div><div>Thanks,</div><div>Teresa</div><span><div><br></div><div> </div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Will work on that.</div><div><br></div><div>Teresa</div><span><div><br></div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><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)<span><font color="#888888"><br><br>- David</font></span></div></div></div></div>
</blockquote></span></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</font></span></div></div>
</blockquote></span></div><span><br><br clear="all"><div><br></div>-- <br><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</span></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>