search for: getsubprograms

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

> 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

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

> On May 4, 2017, at 4:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > > 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,

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 lists.llvm.org> wrote:

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

...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 => &quo...

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

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

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

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

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