[LLVMdev] DwarfDebug problems

[David Blaikie]

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).