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
How do I find and update the lexical blocks? Is, for example, “CloneFunction”
doing this in a way I can copy?
I tried finding the subprogram node in “llvm.dbg.cu” and updating the function:
DISubprogram s(*subprog_iter);
if (s.getFunction() == F) {
s.replaceFunction(NF);
}
But this didn’t seem to have any effect. Do I need to do something similar with
every basic block or something?
On Dec 4, 2013, at 11:00 AM, Eric Christopher <echristo at gmail.com>
wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131204/806e5d28/attachment.html>
On Wed, Dec 4, 2013 at 11:08 AM, Brandon Holt <bholt at cs.washington.edu> wrote:> How do I find and update the lexical blocks? Is, for example, > “CloneFunction” doing this in a way I can copy? >I'm not certain, and unlikely.> I tried finding the subprogram node in “llvm.dbg.cu” and updating the > function: > > DISubprogram s(*subprog_iter); > if (s.getFunction() == F) { > s.replaceFunction(NF); > } > > But this didn’t seem to have any effect. Do I need to do something similar > with every basic block or something? >I'd have thought that RAUW would have replaced the function pointer in the metadata. -eric> > On Dec 4, 2013, at 11:00 AM, Eric Christopher <echristo at gmail.com> wrote: > > 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 > >