similar to: CloneFunctionInto produces invalid debug info

This all looks very similar to a bug in the cloning stuff I fixed recently, so would be indeed good to know if this is still happening on master. On Thu, Jun 15, 2017 at 2:23 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > If you are doing this work based off LLVM trunk, could you send me your > patch to reproduce the problem? > > -- adrian > > On

Can you send me a patch with instructions to reproduce? I can take a look. -- adrian > On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Yes, it does for us. My tree is couple days off the tip, and I see it there. > > Sergei > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Keno Fischer via llvm-dev > Sent:

The if you are cloning into the same LLVM module the CU should not cloned. If don't mind sharing your code, I can try to help diagnose why the CU gets cloned... just send me a patch that applies to trunk and instructions. -- adrian > On Jun 16, 2017, at 1:54 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Sorry… It takes a pass that was not accepted for upstreaming….

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize

I was just going to say: With well-formed debug info it should create a deep copy up until the DISubprogram, but no further. But because the DISubprogram linked to the Function is missing the special handling of the DISubprogram (that would prohibit cloning the DICompileUnit is side-stepped). But then I remembered the discussion we had in

Hi Paul, Thanks for your response. Let me actually post more details visualizing my case. Assuming that can help. so the IR before the opt tool is running is: ; Function Attrs: nounwind define i16 @main() #0 !dbg !13 { entry: %retval = alloca i16, align 1 ... } ; Function Attrs: inlinehint nounwind define internal void @delay(i16 %d) #4 !dbg !69 { entry: %d.addr = alloca i16,

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})

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

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

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()); 362 assert(!Scope->getInlinedAt()); 363 364 const MDNode *SP = Scope->getScopeNode(); 365 366

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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

Thanks Paul, Hi Adrian and David I would really appreciate any comments, thoughts assumptions. If additional information is needed please let me know. Regards, Arsen On Sat, Jan 13, 2018 at 2:54 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > Hi Arsen, we are beyond what I understand about how metadata operates. > Maybe Adrian or David knows. > > --paulr > >

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs.

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

+ Adrian + David Hi Arsen, This sounds like a bug to me. Have you tried reproducing it on trunk? For instance, I see that the relation between DICompileUnit and DISubprogram was changed in the meantime (https://reviews.llvm.org/D19034 <https://reviews.llvm.org/D19034>). If this no longer occurs on master you could bisect the compiler to find the commit(s) that fix this and consider

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

Hi all, I'm dealing with LLVM's debug information metadata, and have run into an interesting edge case. Under normal circumstances, every `DILocalVariable` has a `User` in the form of the `llvm.dbg.*` intrinsic that produced it. Knowing this, I can go from `DILocalVariable` to `MetadataAsValue`, grab the users, and end up at the corresponding instruction + function. In some cases,

Hi All , We have a scenario in our debugger to handle the file index in the debug_ine info like $llvm-dwarfdump -debug-line test.o file_names[ 1]: name: "test.cpp" dir_index: 0 mod_time: 0x00000000 length: 0x00000000 file_names[ 2]: name: "test.cpp" dir_index: 1 mod_time: 0x00000000 length: 0x00000000