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.

Thanks,
Arsen

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.

–paulr

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, align 1

%i = alloca i16, align 1

}

= !{!0}

!llvm.module.flags = !{!84, !85}

!llvm.ident = !{!86}

!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: “clang version 3.8.0 Revision 72230”, isOptimized: true, runtimeVersion: 0, emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !12, globals: !73)

!12 = !{!13, !54, !57, !60, !61, !62, !65, !66, !67, !68, !69}

!13 = distinct !DISubprogram(name: “main”, scope: !14, file: !14, line: 15, type: !15, isLocal: false, isDefinition: true, scopeLine: 15, isOptimized: true, variables: !17)

!54 = distinct !DISubprogram(name: …

!57 = distinct !DISubprogram(name: …

!60 = distinct !DISubprogram(name: …

!61 = distinct !DISubprogram(name: …

!62 = distinct !DISubprogram(name: …

!65 = distinct !DISubprogram(name: …

!66 = distinct !DISubprogram(name: …

!67 = distinct !DISubprogram(name: …

!68 = distinct !DISubprogram(name: …

!69 = distinct !DISubprogram(name: “delay”, scope: !14, file: !14, line: 9, type: !55, isLocal: true, isDefinition: true, scopeLine: 9, flags: DIFlagPrototyped, isOptimized: true, variables: !70)

!70 = !{!71, !72}

!71 = !DILocalVariable(name: “d”, arg: 1, scope: !69, file: !14, line: 9, type: !11)

!72 = !DILocalVariable(name: “i”, scope: !69, file: !14, line: 9, type: !11)

The IR after opt is:

; Function Attrs: nounwind

define i16 @main() #0 !dbg !13 {

entry:

}

= !{!0}

!llvm.module.flags = !{!64, !65}

!llvm.ident = !{!66}

!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: “clang version 3.8.0 Revision 72230”, isOptimized: true, runtimeVersion: 0, emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !12, globals: !54)

!12 = !{!13}

!13 = distinct !DISubprogram(name: “main”, scope: !14, file: !14, line: 15, type: !15, isLocal: false, isDefinition: true, scopeLine: 15, isOptimized: true, variables: !17)

!14 = !DIFile(filename: “main.c”, directory: “path_to_directory”)

!68 = !DILocalVariable(name: “d”, arg: 1, scope: !69, file: !14, line: 9, type: !11)

!69 = distinct !DISubprogram(name: “delay”, scope: !14, file: !14, line: 9, type: !70, isLocal: true, isDefinition: true, scopeLine: 9, flags: DIFlagPrototyped, isOptimized: true, variables: !72)

!73 = !DILocalVariable(name: “i”, scope: !69, file: !14, line: 9, type: !11)

I checked the StripSymbol.cpp file and there is no difference between version I am using (from clang 3.8) and current (6.0.0) version.

As you can see the !12 node does not contain reference to !69 after optimizations which I think is incorrect. I assume that !69 has not been removed because there are two nodes (!68 and !73) referenced to it as the scope. But that should force the transformations to not remove the link from !12. Is it right?

Thank you very much.
Arsen

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 ProcessedSPNodes.insert(SP);

367

368 // Find the subprogram’s DwarfCompileUnit in the SPMap in case the subprogram

369 // was inlined from another compile unit.

370 auto &CU = SPMap[SP];

371 forBothCUs(*CU, [&](DwarfCompileUnit &CU) {

372 CU.constructAbstractSubprogramScopeDIE(Scope);

373 });

374 }

Here I checked that “SPMap.lookup(Scope->getScopeNode());” returns null. If the transformation does right things then probably there is other issue and SPMap[SP] for inlined function should find the main CompileUnit anyway. What do you think about this?

Regards,
Arsen

Hi Arsen, we are beyond what I understand about how metadata operates. Maybe Adrian or David knows.

–paulr

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

  • 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).

If this no longer occurs on master you could bisect the compiler to find the commit(s) that fix this and consider backporting them locally. If not, you should file a bug on bugs.llvm.org and attach the source and commands you’re running. I’d be happy to take a look at it.

Jonas

Hi Jonas,

Thank you very much for your response. It seems that the changes you pointed is the fix for the issue I have.
I am not able to test that revision but I found a workaround using the logic of the fix.

Regards,
Arsen