[llvm-dev] CloneFunction during LTO leads to seg fault?
Sergei Larin via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 17 09:44:57 PST 2016
You can see my solution for a specific problem I face with the stale debug info here
I am first to admit that this treats the effect but not the cause of the issue. In my mind CloneModule should not have created those records in the first place, but I am not sure how to prevent it from doing it elegantly. Maybe Mehdi or Peter can suggest a more direct way...
Without this patch stale debug info can retain references to objects not cloned by CloneModule which might produces relocations to non-existing objects and obviously fails to link.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> -----Original Message-----
> From: Scott A Carr [mailto:carr27 at purdue.edu]
> Sent: Monday, February 15, 2016 5:31 PM
> To: Sergei Larin
> Cc: Tobias Edler von Koch; Mehdi Amini; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] CloneFunction during LTO leads to seg fault?
> 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.
> > 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
> > 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