[llvm-bugs] [Bug 42375] New: UpgradeDebugInfo doesn't process function-level debug info in lazy load path
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Jun 24 13:46:53 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=42375
Bug ID: 42375
Summary: UpgradeDebugInfo doesn't process function-level debug
info in lazy load path
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: JCTremoulet at gmail.com
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
I'm hitting an error (failure to correctly auto-upgrade) processing a .bc file
generated by an older clang with a newer llvm-link. I'm not sure if LTO can
hit the same error or not.
The issue with the older clang is the issue with loop metadata maintenance
during inlining that was fixed with r361149.
***To reproduce:
Start with the cpp code that the testcase which r361149 added
(llvm/test/Transforms/Inline/inlined-loop-metadata.ll) is reduced from:
----------inlined.cpp------------
extern int *Array;
static int bar(unsigned x)
{
int Ret = 0;
for (unsigned i = 0; i < x; ++i)
{
Ret += Array[i] * i;
}
return Ret;
}
int foo(unsigned x)
{
int Bar = bar(x);
return Bar;
}
----------end file---------------
Compile it to a .bc file with clang (older than r361149) and appropriate
optimization flags:
> clang-6.0 -c -emit-llvm -gmlt -O2 inlined.cpp -o inlined.bc
Then use llvm-link (newer than r363725) to link that .bc file (don't need to
link it to anything else):
> llvm-link inlined.bc -o linked.bc
***Observed results:
llvm-link fails with a verifier error on the linked module (i.e. the output of
llvm-link):
!dbg attachment points at wrong subprogram for function
!7 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 12, type:
!8, scopeLine: 13, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition |
DISPFlagOptimized, unit: !0, retainedNodes: !2)
i32 (i32)* @_Z3fooj
br i1 %49, label %50, label %16, !dbg !17, !llvm.loop !23
!24 = !DILocation(line: 5, column: 3, scope: !10)
!10 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type:
!8, scopeLine: 3, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit |
DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !2)
!10 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type:
!8, scopeLine: 3, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit |
DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !2)
llvm-link: error: linked module is broken!
^ the error above is the issue
***Expected results:
llvm-link should have stripped the broken debug info when it read in the input
module. Note that this is the behavior of tools such as llvm-dis (as seen in
the testcase added with r363725, which uses llvm-as):
> llvm-dis inlined.bc -o inlined.ll
!dbg attachment points at wrong subprogram for function
!7 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 12, type:
!8, scopeLine: 13, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition |
DISPFlagOptimized, unit: !0, retainedNodes: !2)
i32 (i32)* @_Z3fooj
br i1 %49, label %50, label %16, !dbg !17, !llvm.loop !23
!24 = !DILocation(line: 5, column: 3, scope: !10)
!10 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type:
!8, scopeLine: 3, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit |
DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !2)
!10 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type:
!8, scopeLine: 3, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit |
DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !2)
llvm-dis: warning: ignoring invalid debug info in inlined.bc
^ the warning above is ok
***Other info:
Looking at this in the debugger, I can see that when UpgradeDebugInfo gets
called in the non-lazy case (the one that llvm-dis always uses, and the one
that llvm-link uses with an explicit -disable-lazy-loading), the verifier
reports the error to it as expected, the warning is emitted, and the debug info
is stripped. But in the lazy case (llvm-link's default), when the verifier
processes the function with the bad debug info, since it hasn't been
materialized, the verifier doesn't visit the debug locs, so the bad debug info
doesn't get stripped but instead gets propagated to the output module, where
the verifier eventually notices it and an error gets reported.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190624/37125176/attachment-0001.html>
More information about the llvm-bugs
mailing list