<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">How do I find and update the lexical blocks? Is, for example, “CloneFunction” doing this in a way I can copy?<div><br></div><div>I tried finding the subprogram node in “llvm.dbg.cu” and updating the function:</div><div><br></div><div><div style="margin: 0px; font-size: 10px; font-family: 'Inconsolata LGC';"><span style="color: #e4a918">DISubprogram</span> s(*subprog_iter);</div><div style="margin: 0px; font-size: 10px; font-family: 'Inconsolata LGC';"><span style="color: #9a64b9">if</span> (s.<span style="color: #3c53a6">getFunction</span>() == F) {</div><div style="margin: 0px; font-size: 10px; font-family: 'Inconsolata LGC';"> s.<span style="color: #3c53a6">replaceFunction</span>(NF);</div></div><div style="margin: 0px; font-size: 10px; font-family: 'Inconsolata LGC';">}</div><div><br></div><div>But this didn’t seem to have any effect. Do I need to do something similar with every basic block or something?</div><div><br></div><div><div><div><br><div><div>On Dec 4, 2013, at 11:00 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">In your transform I'd take a look at things like the individual basic<br>blocks you're replacing and the functions you're replacing and making<br>sure that the various lexical blocks are being changed at the same<br>time...<br><br>-eric<br><br>On Tue, Dec 3, 2013 at 11:12 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br><blockquote type="cite">On Tue, Dec 3, 2013 at 10:07 PM, Brandon Holt <<a href="mailto:bholt@cs.washington.edu">bholt@cs.washington.edu</a>> wrote:<br><blockquote type="cite">Thanks for the quick response.<br><br>I wrote some code to search “llvm.dbg.cu” for the function (right before the<br>failed assertion):<br><br> if (TheCU == nullptr) {<br> errs() << "compile unit: " << TheCU << "\n scopeNode(" <<<br>FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n";<br> auto fn = MF->getFunction();<br> errs() << " fn => " << fn->getName() << "\n";<br><br><br><br> MDNode *node = nullptr;<br> auto mod = fn->getParent();<br> auto dbg = mod->getNamedMetadata("llvm.dbg.cu");<br> for (unsigned ni = 0; ni < dbg->getNumOperands(); ni++) {<br> DICompileUnit cu(dbg->getOperand(ni));<br> auto subs = cu.getSubprograms();<br> for (unsigned si = 0; si < subs.getNumElements(); si++) {<br> DISubprogram sp(subs.getElement(si));<br> if (sp.getFunction() == fn) {<br> node = sp;<br> break;<br> }<br> }<br> }<br> errs() << " (" << node << " ) node => " << *node << "\n";<br> }<br><br>Strangely, the node my code finds *prints* the same, but the pointer is<br>different:<br><br> scopeNode(0x7fe53dc6c2c0) => !{i32 786478, metadata <badref>, metadata<br><badref>, metadata !"grappa_wide_get_pointer", metadata<br>!"grappa_wide_get_pointer", metadata !"", i32 53, metadata <badref>, i1<br>false, i1 true, i32 0, i32 0, null, i32 256, i1 true, i8* (i8*)*<br>@grappa_wide_get_pointer, null, null, metadata <badref>, i32 53} ; [<br>DW_TAG_subprogram ] [line 53] [def] [grappa_wide_get_pointer]<br><br> fn => grappa_wide_get_pointer<br> (0x7fe53bc241b0 ) node => !{i32 786478, metadata <badref>, metadata<br><badref>, metadata !"grappa_wide_get_pointer", metadata<br>!"grappa_wide_get_pointer", metadata !"", i32 53, metadata <badref>, i1<br>false, i1 true, i32 0, i32 0, null, i32 256, i1 true, i8* (i8*)*<br>@grappa_wide_get_pointer, null, null, metadata <badref>, i32 53} ; [<br>DW_TAG_subprogram ] [line 53] [def] [grappa_wide_get_pointer]<br><br><br>Any idea what that could mean?<br></blockquote><br>If you duplicated the function and then RAUW'd it, perhaps the<br>metadata was duplicated in an effort to keep the original metadata in<br>tact.<br><br>I'm really fuzzy on this, but as far as I understand it, identical<br>metadata nodes are implicitly uniqued - when they become<br>non-identical, they may be duplicated so that nodes intending to refer<br>to one node don't end up referring to some mutated node.<br><br>I don't know whether this is at all related to what you're seeing, but<br>I'd consider examining the nodes before and after you replace your<br>function and you might find that that's when the nodes become<br>non-identical...<br><br>Sorry I'm not more precise/more help here.<br><br>- David<br><br><blockquote type="cite"><br>On Dec 3, 2013, at 9:38 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br><br>On Tue, Dec 3, 2013 at 9:04 PM, Brandon Holt <<a href="mailto:bholt@cs.washington.edu">bholt@cs.washington.edu</a>><br>wrote:<br><br>In a pass I’m working on, I’ve done some manipulation of several functions,<br>replacing them with new copies with different types, etc.<br><br>The LLVM IR passes the verifier, but when I have debug symbols enabled<br>(“-g”), I get the following error when Clang generates the Dwarf info (using<br>a very recent build of LLVM/Clang from Git mirror):<br><br>Assertion failed: (TheCU && "Unable to find compile unit!"), function<br>beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617.<br>0 clang-3.4 0x0000000103ff3808<br>llvm::sys::PrintStackTrace(__sFILE*) + 40<br>1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388<br>2 libsystem_platform.dylib 0x00007fff8dd185aa _sigtramp + 26<br>3 libsystem_platform.dylib 000000000000000000 _sigtramp + 1915648624<br>4 clang-3.4 0x0000000103ff3ac6 abort + 22<br>5 clang-3.4 0x0000000103ff3aa1 __assert_rtn + 81<br>6 clang-3.4 0x00000001038bcb70<br>llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 0<br>7 clang-3.4 0x0000000103892677<br>llvm::AsmPrinter::EmitFunctionHeader() + 727<br>8 clang-3.4 0x00000001036229ea<br>llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 170<br>9 clang-3.4 0x0000000103b0fbec<br>llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 60<br>10 clang-3.4 0x0000000103f1244b<br>llvm::FPPassManager::runOnFunction(llvm::Function&) + 347<br>11 clang-3.4 0x0000000103f126db<br>llvm::FPPassManager::runOnModule(llvm::Module&) + 43<br>12 clang-3.4 0x0000000103f12b49<br>llvm::legacy::PassManagerImpl::run(llvm::Module&) + 713<br>13 clang-3.4 0x0000000103f12f5d<br>llvm::legacy::PassManager::run(llvm::Module&) + 13<br>14 clang-3.4 0x0000000104230b3e<br>clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions<br>const&, clang::TargetOptions const&, clang::LangOptions const&,<br>llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 5790<br>15 clang-3.4 0x000000010431b9a7<br>clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 455<br>16 clang-3.4 0x00000001044a7644 clang::ParseAST(clang::Sema&,<br>bool, bool) + 516<br>17 clang-3.4 0x000000010431aab8<br>clang::CodeGenAction::ExecuteAction() + 584<br>18 clang-3.4 0x000000010441c0b6<br>clang::FrontendAction::Execute() + 134<br>19 clang-3.4 0x00000001043f802d<br>clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 973<br>20 clang-3.4 0x0000000103ff6ab4<br>clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4276<br>21 clang-3.4 0x000000010330306d cc1_main(char const**, char<br>const**, char const*, void*) + 925<br>22 clang-3.4 0x00000001033015c3 main + 7283<br>23 libdyld.dylib 0x00007fff8e68d5fd start + 1<br><br><br>(note the line number of the assertion is probably different because I’ve<br>added some prints to help me debug this)<br><br>When I print the MDNode returned by “FnScope->getScopeNode()”, I get lots of<br><badref>’s:<br><br><br>The badrefs are a red herring, so far as I know - they're printed that<br>way even when they're valid references, in my experience.<br><br>That being said, given your assertion it does look like /something/ is up.<br><br>It appears as if the function being emitted is somehow not visited<br>when emitting functions in the list of functions on the compilation<br>units. Somehow it got separated, perhaps.<br><br>!{i32 786478, metadata <badref>, metadata <badref>, metadata<br>!"grappa_wide_get_pointer", metadata !"grappa_wide_get_pointer", metadata<br>!"", i32 53, metadata <badref>, i1 false, i1 true, i32 0, i32 0, null, i32<br>256, i1 true, i8* (i8*)* @grappa_wide_get_pointer, null, null, metadata<br><badref>, i32 53} ; [ DW_TAG_subprogram ] [line 53] [def]<br>[grappa_wide_get_pointer]<br><br><br><br>It looks to me like I must be corrupting the lexical scope information<br>somehow, but I don’t think I’m explicitly touching metadata at all. Any idea<br>what may have caused this? Is there something I must be sure to update<br>within the debug metadata?<br><br><br>I'd look at the cu metadata and the associated subprogram lists to see<br>what's in there and why your subprogram isn't in that list (if I'm<br>reading it right, that's the case - but I could be wrong).<br><br><br></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote></div><br></div></div></div></body></html>