Sebastien DELDON-GNB
2013-Feb-07 11:12 UTC
[LLVMdev] Is there a way to verify that debug info metadata are correct ?
Hi all, I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. On my example I got llc 3.2 to fail on following assertion: llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. 0 llc 0x0000000000ffb43f 1 llc 0x0000000000ffd6ba 2 libpthread.so.0 0x00007f5dd70238f0 3 libc.so.6 0x00007f5dd6312a75 gsignal + 53 4 libc.so.6 0x00007f5dd63165c0 abort + 384 5 libc.so.6 0x00007f5dd630b941 __assert_fail + 241 6 llc 0x0000000000b22f20 llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 3232 7 llc 0x0000000000b0ea9b llvm::AsmPrinter::EmitFunctionBody() + 3291 8 llc 0x0000000000895f1d 9 llc 0x0000000000f995cd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 10 llc 0x0000000000f996b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 11 llc 0x0000000000f99141 llvm::MPPassManager::runOnModule(llvm::Module&) + 497 12 llc 0x0000000000f992bb llvm::PassManagerImpl::run(llvm::Module&) + 171 13 llc 0x000000000052feb2 main + 5778 14 libc.so.6 0x00007f5dd62fdc4d __libc_start_main + 253 15 llc 0x000000000052bc29 Stack dump: 0. Program arguments: /home/deldon/Work/dev/pgi/linux86/share/llvm/3.2/bin/llc localvar2.ll -march=x86 -o localvar2.s 1. Running pass 'Function Pass Manager' on module 'localvar2.ll'. 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@foo' To me debug metadata, I'm generating, seem correct, but I can't find why this assert is happening. Is there any way to verify that metadata are correct ? Best Regards Seb
Eli Bendersky
2013-Feb-11 17:20 UTC
[LLVMdev] Is there a way to verify that debug info metadata are correct ?
On Thu, Feb 7, 2013 at 3:12 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote:> Hi all, > > I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. > On my example I got llc 3.2 to fail on following assertion: > > > llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. > 0 llc 0x0000000000ffb43f > 1 llc 0x0000000000ffd6ba > 2 libpthread.so.0 0x00007f5dd70238f0 > 3 libc.so.6 0x00007f5dd6312a75 gsignal + 53 > 4 libc.so.6 0x00007f5dd63165c0 abort + 384 > 5 libc.so.6 0x00007f5dd630b941 __assert_fail + 241 > 6 llc 0x0000000000b22f20 llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 3232 > 7 llc 0x0000000000b0ea9b llvm::AsmPrinter::EmitFunctionBody() + 3291 > 8 llc 0x0000000000895f1d > 9 llc 0x0000000000f995cd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 > 10 llc 0x0000000000f996b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 > 11 llc 0x0000000000f99141 llvm::MPPassManager::runOnModule(llvm::Module&) + 497 > 12 llc 0x0000000000f992bb llvm::PassManagerImpl::run(llvm::Module&) + 171 > 13 llc 0x000000000052feb2 main + 5778 > 14 libc.so.6 0x00007f5dd62fdc4d __libc_start_main + 253 > 15 llc 0x000000000052bc29 > Stack dump: > 0. Program arguments: /home/deldon/Work/dev/pgi/linux86/share/llvm/3.2/bin/llc localvar2.ll -march=x86 -o localvar2.s > 1. Running pass 'Function Pass Manager' on module 'localvar2.ll'. > 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@foo' > > > To me debug metadata, I'm generating, seem correct, but I can't find why this assert is happening. > Is there any way to verify that metadata are correct ? >I'm not aware of any verifier for the debug metadata (patches welcome - this would be great to have). However, I'd say you're in good shape having a clean assertion triggering. All debugging metadata nodes are linked through "scope" or "context" fields (their parent, essentially). Something went wrong in the linking in the medatada you generate. I suppose you're familiar with http://llvm.org/docs/SourceLevelDebugging.html, though I should point out that "Reference to context" is what you're looking for in MDNodes. Synthesize simple C code that is similar to what you're trying to generate, run it through clang -g and see the MDNodes it creates, and how these are linked. Eli
David Blaikie
2013-Feb-11 17:42 UTC
[LLVMdev] Is there a way to verify that debug info metadata are correct ?
On Thu, Feb 7, 2013 at 3:12 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote:> Hi all, > > I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata.If at all possible please migrate to using the DIBuilder interface. I'm trying to port DragonEgg over to DIBuilder at the moment with the intent that once that happens I'll be able to freely modify the debug info metadata schema by modifying DIBuilder without concern for other clients creating debug info metadata separately. - David> On my example I got llc 3.2 to fail on following assertion: > > > llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. > 0 llc 0x0000000000ffb43f > 1 llc 0x0000000000ffd6ba > 2 libpthread.so.0 0x00007f5dd70238f0 > 3 libc.so.6 0x00007f5dd6312a75 gsignal + 53 > 4 libc.so.6 0x00007f5dd63165c0 abort + 384 > 5 libc.so.6 0x00007f5dd630b941 __assert_fail + 241 > 6 llc 0x0000000000b22f20 llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) + 3232 > 7 llc 0x0000000000b0ea9b llvm::AsmPrinter::EmitFunctionBody() + 3291 > 8 llc 0x0000000000895f1d > 9 llc 0x0000000000f995cd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 > 10 llc 0x0000000000f996b3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 > 11 llc 0x0000000000f99141 llvm::MPPassManager::runOnModule(llvm::Module&) + 497 > 12 llc 0x0000000000f992bb llvm::PassManagerImpl::run(llvm::Module&) + 171 > 13 llc 0x000000000052feb2 main + 5778 > 14 libc.so.6 0x00007f5dd62fdc4d __libc_start_main + 253 > 15 llc 0x000000000052bc29 > Stack dump: > 0. Program arguments: /home/deldon/Work/dev/pgi/linux86/share/llvm/3.2/bin/llc localvar2.ll -march=x86 -o localvar2.s > 1. Running pass 'Function Pass Manager' on module 'localvar2.ll'. > 2. Running pass 'X86 AT&T-Style Assembly Printer' on function '@foo' > > > To me debug metadata, I'm generating, seem correct, but I can't find why this assert is happening. > Is there any way to verify that metadata are correct ? > > Best Regards > Seb > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Eli Bendersky
2013-Feb-11 17:47 UTC
[LLVMdev] Is there a way to verify that debug info metadata are correct ?
On Mon, Feb 11, 2013 at 9:42 AM, David Blaikie <dblaikie at gmail.com> wrote:> On Thu, Feb 7, 2013 at 3:12 AM, Sebastien DELDON-GNB > <sebastien.deldon at st.com> wrote: >> Hi all, >> >> I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. > > If at all possible please migrate to using the DIBuilder interface. > I'm trying to port DragonEgg over to DIBuilder at the moment with the > intent that once that happens I'll be able to freely modify the debug > info metadata schema by modifying DIBuilder without concern for other > clients creating debug info metadata separately. >It would be great if you could document that "schema" while you're at it. Eli