[LLVMdev] DwarfDebug problems
Brandon Holt
bholt at cs.washington.edu
Wed Dec 4 11:08:18 PST 2013
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>
More information about the llvm-dev
mailing list