[llvm-dev] CloneFunction during LTO leads to seg fault?

Scott A Carr via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 15 15:30:55 PST 2016


Hi Sergei,

I would like to see a patch if you have one.  

StripDeadDebugInfo doesn’t work for me because the new debug info nodes (after clone) are not the child of any llvm.dbg.cu node.

I’m not sure how deleting the new metadata nodes would work because they are referenced in the cloned functions.

Thanks,
Scott

> On Feb 12, 2016, at 11:28 AM, Sergei Larin <slarin at codeaurora.org> wrote:
> 
> In general I use DebugInfoFinder and clear out Metadata if GV in null or GV->isDeclaration().
> 
> If there is any interest, I can post that patch...
> 
> Sergei
> 
> ---
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 
>> -----Original Message-----
>> From: Tobias Edler von Koch [mailto:tobias at codeaurora.org]
>> Sent: Friday, February 12, 2016 9:51 AM
>> To: Mehdi Amini; Scott A. Carr
>> Cc: llvm-dev at lists.llvm.org; Sergei Larin
>> Subject: Re: [llvm-dev] CloneFunction during LTO leads to seg fault?
>> 
>> On 02/11/2016 10:05 AM, Mehdi Amini via llvm-dev wrote:
>>>> Is this a bug?  Is there an assumption that a function won't be cloned after
>> inlining?  Is there an assumption that the debug info metadata nodes are well
>> formed when they get to DwarfDebug?
>>> There shouldn't be such assumptions, and if there is such an assumption
>> the compiler should assert instead of segfaulting (assuming you built with
>> assertions).
>>> My guess i that CloneFunction 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.
> 
> 



More information about the llvm-dev mailing list