search for: subprograms

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!"); DISubprogram SP(SPNode); // If we're updating an abstract DIE, then we will be adding...

...orking 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 the DISubprogram, so if the llvm::Function goes away, so does the associated DISubprogram) I'm not sure if this caused a regression, but at least seems to miss a possible improvement: During IR linking (for LTO,...

...bout 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 the DISubprogram, so if the llvm::Function goes > away, so does the associated DISubprogram) > > I'm not sure if this caused a regression, but at least seems to miss a > possible improvement: >...

...bout 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 the DISubprogram, so if the llvm::Function goes > away, so does the associated DISubprogram) > > I'm not sure if this caused a regression, but at least seems to miss a > possible improvement: >...

...anges 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 the DISubprogram, so if the llvm::Function goes >> away, so does the associated DISubprogram) >> >> I'm not sure if this caused a regression, but at least seems to miss a >> possibl...

...- 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 the DISubprogram, so if the llvm::Function goes away, so does the associated DISubprogram) > > I'm not sure if this caused a regression, but at least seems to miss a possible improvement: > > During I...

...anges 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 the DISubprogram, so if the llvm::Function goes >> away, so does the associated DISubprogram) >> >> I'm not sure if this caused a regression, but at least seems to miss a >> possibl...

...ed > 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 the DISubprogram, so if the llvm::Function goes > away, so does the associated DISubprogram) > > > > I'm not sure if this caused a regression, but at least seems to miss a > possible improvem...

...orking 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 the DISubprogram, so if the llvm::Function goes away, so does the associated DISubprogram) I'm not sure if this caused a regression, but at least seems to miss a possible improvement: During IR linking (for LTO,...

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

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

> 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

...bout 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 the DISubprogram, so if the llvm::Function goes > away, so does the associated DISubprogram) > > I'm not sure if this caused a regression, but at least seems to miss a > possible improvement: >...

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

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

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

...ere relying in the existence of this node, and things broke once we switched from LLVM 2.8 to 3.0. Is there an alternative location where all the subprogram debug descriptors (DW_TAG_subprogram) can be obtained? You can use DebugInfoFinder from DebugInfo.h. It provides an iterator to walk over all subprograms. - Devang --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the...

...how much inlining has happened. > > (I have a draft of the writer side, still working on the reader.) > > 2. Reverse the `DISubprogram`/`DICompileUnit` link (David and I have > talked about this in the past in barely-related threads). The > direct effect is that subprograms that are not pointed at by any > code (!dbg attachments or @llvm.dbg.value intrinsics) get dropped. > > This addresses problem (c). If a consumer is only linking/loading a > subset of a module's functions, this naturally filters subprograms > to the relevant one...

...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/bugs? > >> Now that the Function <-> DISubprogram connection has been reversed, I'm not entirely sure it's still a necessary precaution. >> >> - It broke a several uniquing...

...nk 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/bugs? > Now that the Function <-> DISubprogram connection has been reversed, I'm > not entirely sure it's still a necessary precaution. > > - It broke a several uniquing cycles involving...