[LLVMdev] DwarfDebug problems

[Brandon Holt]

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:

> !{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?

Thanks,
-Brandon