<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 13, 2013, at 1:23 AM, Eric Christopher wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
+/// Climb up the parent chain to get the compile unit DIE this DIE belongs to.<br>
+DIE *DIE::getCompileUnit() const{<br>
+ DIE *p = getParent();<br>
+ while (p) {<br>
+ if (p->getTag() == dwarf::DW_TAG_compile_unit)<br>
+ return p;<br>
+ p = p->getParent();<br>
+ }<br>
+ return NULL;<br>
+}<br>
+<br></blockquote><div><br></div><div style="">Shouldn't this be unreachable or is there some case where we have orphaned DIEs?</div></div></div></div></blockquote>We should not generate orphaned DIEs, and should be able to change "return NULL" to unreachable.</div><div>But I fixed an issue before where we generated orphaned DIEs. I can check in a separate change for this.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+/// For a given compile unit DIE, returns offset from beginning of debug info.<br>
+unsigned DwarfUnits::getCUOffset(DIE *Die) {<br>
+ for (SmallVector<CompileUnit *, 1>::iterator I = CUs.begin(),<br>
+ E = CUs.end(); I != E; ++I) {<br>
+ CompileUnit *TheCU = *I;<br>
+ if (TheCU->getCUDie() == Die)<br>
+ return TheCU->getDebugInfoOffset();<br>
+ }<br>
+ return 0;<br>
+}<br>
+<br></blockquote><div><br></div><div style="">Can you make this a little more safe? Assert that it's a compile unit on entry and that'd hopefully make the return 0 also be unreachable?</div></div></div></div></blockquote>Sure.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div style="">Also can you show at least some of the debug info for how you made your determination? This seems odd (at least the abstract origin part) and I'd like to understand how we lto'd something together and got this.</div></div></div></div></blockquote>As I said in the commit message, I only saw this when building the kernel with LTO and rdynamic, and this only happened 6 times and we got 6 verification errors.</div><div>With this fix, verification runs fine.</div><div>Is it strange to you that abstract_origin points to a DIE in a different CU?</div><div><br></div><div>Manman<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div style=""><br></div><div style="">Thanks!</div><div style=""><br></div><div style="">-eric</div></div><br></div></div>
</blockquote></div><br></body></html>