<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 13, 2017 at 11:09 PM Dean Michael Berris <<a href="mailto:dberris@google.com">dberris@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 13 Sep 2017, at 23:07, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_-7415667402279584597Apple-interchange-newline"><div><div dir="ltr" style="font-family:HelveticaNeue;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 12, 2017 at 10:42 PM Dean Michael Berris via Phabricator via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">dberris created this revision.<br>Herald added a subscriber: aprantl.<br><br>XRay had been assuming that the previous section is the "text" section<br>of the function. Unfortunately for in-lined functions where we're also<br>generating the comdat definition for debugging purposes, we may be<br>coming from a section that isn't "text" (could be .zdebug_types).<br></blockquote><div><br>This statement "unfortunately for in-lined functions where we're also generating the comdat definition for debugging purposes" is still confusing to me - I don't think this has anything to do with comdats.<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Yes, I've updated the description. PTAL.</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:HelveticaNeue;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><br>Indeed I think the test case you mentioned having had no inline functions at all - just that if type units are enabled and any debug types are emitted during endFunction, then that causes a switch to the debug_types section, rather than the text section. (most of the DWARF emission is delayed - we mostly don't switch to DWARF sections and produce DWARF bytes until the end of the module - except for type units, since they're whole/complete by themselves the moment we emit the type, so for those we do it immediately - causing section changes)<br> </div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>That's correct. Please see the updated description?</div></div></div></blockquote><div><br>Ah, sure.<br><br>Though the description and test centers around the linker failure caused by this bug + split-dwarf - it looks like split-dwarf exposed a bug that'd be there even without split-dwarf. That the instrmap was referring to the wrong section/data. So I'd probably test that directly (objdump -r to test the relocations refer to the right sections, test without split-dwarf because that's not integral to the underlying bug, no need to worry about/mention fission or objcopy except perhaps by way of explaining how the issue was discovered if you think that's particularly helpful for future readers).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:HelveticaNeue;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>This fixes an issue with combining -gsplit-dwarf and -fxray-instrument<br>for functions inlined, where the original definition may be lowered<br>into the debug sections. When the debug section is stripped, we're<br>left with references from the xray_instr_map to the debug section. The<br>change now uses the function's symbol instead of the previous<br>section's start symbol.<br><br><br><a href="https://reviews.llvm.org/D37791" rel="noreferrer" target="_blank">https://reviews.llvm.org/D37791</a><br><br>Files:<br> <span class="m_-7415667402279584597Apple-converted-space"> </span>lib/CodeGen/AsmPrinter/AsmPrinter.cpp<br><br><br>Index: lib/CodeGen/AsmPrinter/AsmPrinter.cpp<br>===================================================================<br>--- lib/CodeGen/AsmPrinter/AsmPrinter.cpp<br>+++ lib/CodeGen/AsmPrinter/AsmPrinter.cpp<br>@@ -2785,7 +2785,7 @@<br>   MCSection *InstMap = nullptr;<br>   MCSection *FnSledIndex = nullptr;<br>   if (MF->getSubtarget().getTargetTriple().isOSBinFormatELF()) {<br>-    auto Associated = dyn_cast<MCSymbolELF>(PrevSection->getBeginSymbol());<br>+    auto Associated = dyn_cast<MCSymbolELF>(CurrentFnSym);<br>     assert(Associated != nullptr);<br>     auto Flags = ELF::SHF_WRITE | ELF::SHF_ALLOC | ELF::SHF_LINK_ORDER;<br>     std::string GroupName;<br><br><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a></blockquote></div></div></div></blockquote></div></div></blockquote></div></div>