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