search for: getsubprogram

...I need to enable any other analysis passes in order to populate the data? My related snippet of code is like the following: NamedMDNode *M_Nodes = M.getNamedMetadata("llvm.dbg.cu"); for (unsigned i = 0, e = M_Nodes->getNumOperands(); i != e; ++i) { DIArray SPs = CU.getSubprograms(); for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++ i) { DISubprogram SP(SPs.getElement(i)); DIArray Vars = SP.getVariables(); for (unsigned i2 = 0, e2 = Vars.getNumElements(); i2 != e2; ++i2) { DIVariable DV(Vars.getElement(i)); DV....

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs. -------------------...

Not sure what you tried/how it didn't work - could you explain more? You could scan through all the llvm::Functions in an llvm::Module and look at the debug info associated with them (getSubprogram) then check the location of that debug info. - Dave On Tue, May 15, 2018 at 12:46 AM Ridwan Shariffdeen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I want to retrieve a function from a source line-number, is this something possible to achieve? > I tried the foll...

...her analysis passes in order to populate the data? > > My related snippet of code is like the following: > > NamedMDNode *M_Nodes = M.getNamedMetadata("llvm.dbg.cu"); > for (unsigned i = 0, e = M_Nodes->getNumOperands(); i != e; ++i) { > DIArray SPs = CU.getSubprograms(); > for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++ i) { > DISubprogram SP(SPs.getElement(i)); > DIArray Vars = SP.getVariables(); > for (unsigned i2 = 0, e2 = Vars.getNumElements(); i2 != e2; ++i2) { > DIVariable DV(Vars.getElement...

Hi, I want to retrieve a function from a source line-number, is this something possible to achieve? I tried the following code snippet with LLVM-7 but it doesn't seem to workhttp://llvm.org/docs/SourceLevelDebugging.html#ccxx_frontend <http://llvm.org/docs/SourceLevelDebugging.html#ccxx_frontend:> Is there specific documentation I can refer to implement this? Thanks -- *Rtr. PP

...: > > Alrighty, a little fuzzy on how best to implement this - Adrian, you've probably got the most context here as to how to wrangle this. > > My first attempt was in IRMover.cpp, IRLinker::linkFunctionBody - after metadata is copied over, create a new subprogram derived from Dst.getSubprogram, only changing the CU over (to the first, if any, CU on the llvm.dbg.cu <http://llvm.dbg.cu/> named metadata). > > This is insufficient because all the metadata in the function (variables, etc) doesn't get updated and chains up to the old DISubprogram still. For this part you shou...

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lis...

...a? >>> >>> My related snippet of code is like the following: >>> >>> NamedMDNode *M_Nodes = M.getNamedMetadata("llvm.dbg.cu"); >>> for (unsigned i = 0, e = M_Nodes->getNumOperands(); i != e; ++i) { >>> DIArray SPs = CU.getSubprograms(); >>> for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++ i) { >>> DISubprogram SP(SPs.getElement(i)); >>> DIArray Vars = SP.getVariables(); >>> for (unsigned i2 = 0, e2 = Vars.getNumElements(); i2 != e2; >>> ++i2) {...

On Thu, May 4, 2017 at 7:22 AM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > So Dehao and I have been dealing with some of the nitty gritty details of > > debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

...t" map. That highlights a problem that my proposal doesn't solve on its own. While this proposal creates a "Function -> Subprogram" map, there still isn't a "Subprogram -> CompileUnit" map -- that would still (for now) be stored implicitly via `MDCompileUnit::getSubprograms()`. Why isn't this map encoded in the `scope:` chain? Because many of the `scope:` chains currently terminate at `MDFile`s or `null` instead of `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains to be identical. (I have a vague plan for fixing this, too: (1) move ownershi...

...e() << "\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 => &qu...

...programAttributes(SP, SPDie); return &SPDie; } It assumes that later when the function is finalized the attributes will be applied, which is called from this code: void DwarfDebug::finishSubprogramDefinitions() { for (auto &F : MMI->getModule()->functions()) if (auto *SP = F.getSubprogram()) if (ProcessedSPNodes.count(SP) && SP->getUnit()->getEmissionKind() != DICompileUnit::NoDebug) forBothCUs(*CUMap.lookup(SP->getUnit()), [&](DwarfCompileUnit &CU) { CU.finishSubprogramDefinition(SP); <------------- In our case...

Let's forget about my malformed IR if it is adding additional confusion here. I mentioned it here to ease the conversation, but if it is causing confusion rather than making the discussion flow easier, then we better ignore it. The whole triggering point for this email initiative is - one of the applications is crashing with the stack trace that I mentioned earlier. The crash is during the

...*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; >> } >> } >> } >>...

...hat highlights a problem that my proposal doesn't solve on its own. > While this proposal creates a "Function -> Subprogram" map, there still > isn't a "Subprogram -> CompileUnit" map -- that would still (for now) > be stored implicitly via `MDCompileUnit::getSubprograms()`. > > I guess this is (also?) what I was thinking about. > > Why isn't this map encoded in the `scope:` chain? Because many of the > `scope:` chains currently terminate at `MDFile`s or `null` instead of > `MDCompileUnit`s. Why? Because LTO type uniquing needs scope ch...

...gt; > 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() << " (" &...

...zer is evil" that was not my intent, sorry! No, no, I did not mean you implied that :) Just wanted to make sure everyone understand that this is not libFuzzer-specific. Looking at lib/Transforms/Instrumentation/SanitizerCoverage.cpp: DebugLoc EntryLoc; if (IsEntryBB) { if (auto SP = F.getSubprogram()) EntryLoc = DebugLoc::get(SP->getScopeLine(), 0, SP); ... } else { EntryLoc = IP->getDebugLoc(); } IRBuilder<> IRB(&*IP); IRB.SetCurrentDebugLocation(EntryLoc); So, using this I assumed that the newly generated instructions have proper debug info, and so far it...

...; >>> 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; >>> } >>> } >...

It might be a wider problem than libfuzzer. I did want to raise the problem asap and libfuzzer is something we know has the problem. If it came across as "libfuzzer is evil" that was not my intent, sorry! --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 2:53 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev]