[llvm-dev] StripDeadDebugInfo for static inline functions.

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 12 10:21:13 PST 2018

I'm not as familiar with all the ins and outs of metadata as maybe I should be, but ultimately the inlined function should have a DWARF description contained within the description of the caller (which is why you're seeing the call to constructAbstractSubprogramScopeDIE).  That suggests that the DISubprogram for the inlined function ought to remain, and its scope should be the DICompileUnit.

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 DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is reference from the DILocalVariables to the DISubprogram it remains (IMHO).
This caused to a segmentation fault while running llc on the optimized IR file at function "constructAbstractSubprogramScopeDIE" in file DwarfDebug.cpp because the scope of the DISubprogram is null (I assume it should be the DICompileUnit).

So I would like to know what would be the correct solution for this issue: Update optimization to not remove reference from the subprograms list, or to skip finding scope in llc.

Any help is highly appreciated.



If it's not fun you're not doing it right -- Fran Tarkenton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180112/5e7d92f1/attachment-0001.html>

More information about the llvm-dev mailing list