search for: stripdeaddebuginfo

...he DISubprogram for the inlined function ought to remain, and its scope should be the DICompileUnit. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Arsen Hakobyan via llvm-dev Sent: Friday, January 12, 2018 1:57 AM To: llvm-dev at lists.llvm.org Subject: [llvm-dev] StripDeadDebugInfo for static inline functions. Hi all, I would like to understand the strip-dead-debug-info transformation. In my test case there is a static inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICom...

Hi all, I would like to understand the strip-dead-debug-info transformation. In my test case there is a static inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is

...tion hasn't been tested with this case and it is a > bug. > > The problem is that the Clone* functions don't clean up debug info at all. This > also affects split codegen in LTO (as is, it won't work if you have debug info). > A work-around is to run something similar to StripDeadDebugInfo after > cloning - Sergei (cc'ed) has seen some success using an approach based on > that. > > Tobias > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project.

...ta operates. > Maybe Adrian or David knows. > > --paulr > > > > *From:* Arsen Hakobyan [mailto:hakobyan.ars at gmail.com] > *Sent:* Friday, January 12, 2018 12:16 PM > *To:* Robinson, Paul > *Cc:* llvm-dev at lists.llvm.org; David Blaikie > *Subject:* Re: [llvm-dev] StripDeadDebugInfo for static inline functions. > > > > Just one update: > > > > the function causing the segmentation fault is the following: > > > > 359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope > *Scope) { > > 360 assert(Scope && Scop...

.... >> >> --paulr >> >> >> >> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Arsen >> Hakobyan via llvm-dev >> *Sent:* Friday, January 12, 2018 1:57 AM >> *To:* llvm-dev at lists.llvm.org >> *Subject:* [llvm-dev] StripDeadDebugInfo for static inline functions. >> >> >> >> Hi all, >> >> >> >> I would like to understand the strip-dead-debug-info transformation. >> >> In my test case there is a static inline function with two local >> variables. >> >>...

...;> > From: Arsen Hakobyan [mailto:hakobyan.ars at gmail.com <mailto:hakobyan.ars at gmail.com>] > Sent: Friday, January 12, 2018 12:16 PM > To: Robinson, Paul > Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; David Blaikie > Subject: Re: [llvm-dev] StripDeadDebugInfo for static inline functions. > > > > Just one update: > > > > the function causing the segmentation fault is the following: > > > > 359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope *Scope) { > 360 assert(Scope && Sc...

Hi Arsen, we are beyond what I understand about how metadata operates. Maybe Adrian or David knows. --paulr From: Arsen Hakobyan [mailto:hakobyan.ars at gmail.com] Sent: Friday, January 12, 2018 12:16 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org; David Blaikie Subject: Re: [llvm-dev] StripDeadDebugInfo for static inline functions. Just one update: the function causing the segmentation fault is the following: 359 void DwarfDebug::constructAbstractSubprogramScopeDIE(LexicalScope *Scope) { 360 assert(Scope && Scope->getScopeNode()); 361 assert(Scope->isAbstractScope());...

...nd its scope should be the DICompileUnit. > > --paulr > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Arsen > Hakobyan via llvm-dev > *Sent:* Friday, January 12, 2018 1:57 AM > *To:* llvm-dev at lists.llvm.org > *Subject:* [llvm-dev] StripDeadDebugInfo for static inline functions. > > > > Hi all, > > > > I would like to understand the strip-dead-debug-info transformation. > > In my test case there is a static inline function with two local variables. > > It appears that the function is already inlined before &g...

y > On Feb 11, 2016, at 8:00 AM, Scott A. Carr <carr27 at purdue.edu> wrote: > > Hello again, > > I've narrowed down my issue to a small test case. The core of the issue is that CloneFunction (with ModuleLevelChanges=true) on a function that has had other functions inlined into it generates orphan debug info metadata nodes. Then when this module is emitted, DwarfDebug

Sorry if this has been discussed already... I am trying to understand whether there is an underlying reason why llvm::CloneModule takes argument function ShouldCloneDefinition to discriminate on objects being cloned, but blindly copies all named metadata...? In my case this results in debug nodes that are creating uses/relocations for global objects that were _not_ copied per