search for: subprogram

Hi, I am working on an issue where a subprogram created here is having abstract_origin pointing to nowhere. DIE *DwarfDebug::updateSubprogramScopeDIE(CompileUnit *SPCU, const MDNode *SPNode) { DIE *SPDie = SPCU->getDIE(SPNode); assert(SPDie && "Unable to find subprogram DIE!");...

...uch arcane context here. On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> wrote: Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list of subprograms, subprograms specify which CU they come from - and the llvm::Function references...

...gt; On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions > were deduplicated in LTO linking, the relationship between a CU and > DISubprogram was inverted (instead of a CU maintaining a list of > subprograms, subprograms specify which CU they come from - and the &g...

...gt; On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions > were deduplicated in LTO linking, the relationship between a CU and > DISubprogram was inverted (instead of a CU maintaining a list of > subprograms, subprograms specify which CU they come from - and the &g...

...2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >> Branching off from a discussion of improvements to DIGlobalVariable >> representations that Adrian's working on - got me thinking about related >> changes that have already been made to DISubprogram. >> >> To reduce duplicate debug info when things like linkonce_odr functions >> were deduplicated in LTO linking, the relationship between a CU and >> DISubprogram was inverted (instead of a CU maintaining a list of >> subprograms, subprograms specify which CU they co...

...gt; On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list of subprograms, subprograms specify which CU they come from - and the llvm::Function r...

...2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >> Branching off from a discussion of improvements to DIGlobalVariable >> representations that Adrian's working on - got me thinking about related >> changes that have already been made to DISubprogram. >> >> To reduce duplicate debug info when things like linkonce_odr functions >> were deduplicated in LTO linking, the relationship between a CU and >> DISubprogram was inverted (instead of a CU maintaining a list of >> subprograms, subprograms specify which CU they co...

...0:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > > > To reduce duplicate debug info when things like linkonce_odr functions > were deduplicated in LTO linking, the relationship between a CU and > DISubprogram was inverted (instead of a CU maintaining a list of > subprograms, subprograms specify which CU they come from -...

Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list of subprograms, subprograms specify which CU they come from - and the llvm::Function references...

Hi I was wondering whether I can extract the function signature from the dwarf debugging information or symbol table. I mean the argument list and the return variables. I know that in dwarf debugging information, a subprogram represents a function. However, I could not find the information that is related to the function signature. Any ideas? Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180930/edcfe58...

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

> On 2016-Jan-15, at 06:46, Keno Fischer <kfischer at college.harvard.edu> wrote: > > Looking at this again, I think I was under the mistaken impression that the DISubprogram's scope would have to be the compile unit, but it seems we also currently allow it to be a DIFile (or any other kind of scope). In that case, I suppose the behavior that the backend expects is that every DISubprogram is referenced from some DICompileUnit contained in llvm.dbg.cu. I'll imple...

...s below. =) On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> wrote: > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions > were deduplicated in LTO linking, the relationship between a CU and > DISubprogram was inverted (instead of a CU maintaining a list of > subprograms, subprograms specify which CU they come from - and the &g...

...ion for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list, and so forth). How can I remove that unused stuff? (It continues on to generated object files, which is extra undesirable when there is a lot of this.) > > In theory, every metadata that is not attached to a real value (or a > na...

Hello, According to the documentation here - http://llvm.org/docs/SourceLevelDebugging.html: >> All subprogram descriptors are collected by a named metadata !llvm.dbg.sp. LLVM seems to have lost the ability to generate this metadata node in r126871, when DIFactory was removed. Is this an intended change? We were relying in the existence of this node, and things broke once we switched from LLVM 2.8 to 3.0....

Hi, If I have an instance of DISubprogram, can I get the debug info of local variables of the function, including parameters? I tried to use the getVariables() function defined in DISubprogram, but it seemed to return an empty DIArray node when I ran my pass alone using opt. Do I need to enable any other analysis passes in order to pop...

...s.uiuc.edu Subject: Re: generating !llvm.dbg.sp On Feb 9, 2012, at 7:17 AM, "Bendersky, Eli" <eli.bendersky at intel.com<mailto:eli.bendersky at intel.com>> wrote: Hello, According to the documentation here -http://llvm.org/docs/SourceLevelDebugging.html: >> All subprogram descriptors are collected by a named metadata!llvm.dbg.sp. LLVM seems to have lost the ability to generate this metadata node in r126871, when DIFactory was removed. Is this an intended change? Yes, I'll update the doc. We were relying in the existence of this node, and things broke once w...

...king? > > > c) Emitting unnecessary `DI*` instances (that aren't relevant to code). > > Here is my recollection of some peak memory stats on a small testcase > during thin-LTO, which should be a decent indicator of (b): > > - ~150MB: DILocation > - ~100MB: DISubprogram > - ~70MB: DILocalVariable > - ~50MB: (cumulative) DIType descendents > > It looks, suprisingly, like types are not the primary bottleneck. > > There are caveats: > > - `DISubprogram` declarations -- member function descriptors -- are > part of the type hiera...

...> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). >> >> - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile units would coalesce. > > Any idea why that ^ was a probl...

On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > A few disjoint thoughts; sorry they're so delayed (I skimmed the responses > below, and I think these are still relevant/not covered elsewhere). > > Firstly, why *should* DISubprogram definitions be distinct? There were > two reasons this was valuable (this was from before there was a cu: link). > > - It helped to fix long-standing bugs in the IRLinker, where > uniqued-DISubprograms in different compile units would coalesce. > Any idea why that ^ was a problem/b...