<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [DebugInfo@O2] DbgEntityHistoryCalculator allows stack-slot variable locations to leak between blocks"
href="https://bugs.llvm.org/show_bug.cgi?id=41600">41600</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[DebugInfo@O2] DbgEntityHistoryCalculator allows stack-slot variable locations to leak between blocks
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>wrong-debug
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jeremy.morse.llvm@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>aprantl@apple.com, bjorn.a.pettersson@ericsson.com, chackz0x12@gmail.com, david.stenberg@ericsson.com, greg.bedwell@sony.com, llvm-bugs@lists.llvm.org, orlando.hyams@sony.com, paul.robinson@am.sony.com, stephen.tozer@sony.com
</td>
</tr></table>
<p>
<div>
<pre>DbgEntityHistoryCalculator currently appears to allow stack-slot-referencing
debug variable locations to fall through into blocks where they are no longer
valid. The IR at the bottom of this ticket replicates this scenario, when run
with "llc input.ll -O0 -o out.o -filetype=obj -mtriple=x86_64--" (I'm using
LLVM r358073).
Examine the output object file disassembly and the location list for the "bees"
variable. I get:
-------->8--------
DW_AT_location (0x00000000
[0x000000000000000d, 0x000000000000001f): DW_OP_breg7
RSP-4
[0x000000000000001f, 0x000000000000002c): DW_OP_lit1,
DW_OP_stack_value
[0x000000000000002c, 0x0000000000000042): DW_OP_lit2,
DW_OP_stack_value)
--------8<--------
Which is roughly the right thing, as the IR states the variable lies first on
the stack, and then it has constant values. However, looking at the
disassembly, the range of the RSP-4 entry covers both the "entry" IR block and
the "bb1" IR block. It should not cover the "bb1" block because there are no
paths to that block where the variable location is not redefined. If one adds
-stop-after=livedebugvalues to the command line, we see that the bb1 block
correctly does not have a DBG_VALUE in it at all, because livedebugvalues can't
guarantee the variable location in that block. It would appear that
DbgEntityHistoryCalculator then allows the DBG_VALUE in the entry block to leak
into bb1.
Having just frobbed this for D59431, the problem seems to be that while we can
identify the open debug range as being something we should close, we then don't
because the ChangingRegs set in DbgEntityHistoryCalculator indicates that
things referring to unchanging registers (i.e. the stack pointer) should never
be clobbered. It's not clear why this is, and removing that facility makes
tests fail; I haven't dug any further.
-------->8--------
declare void @llvm.dbg.value(metadata, metadata, metadata)
declare void @llvm.dbg.addr(metadata, metadata, metadata)
define dso_local i32 @foo(i1 %cond, i32 %input) !dbg !5 {
entry:
%something = alloca i32
store i32 0, i32* %something
call void @llvm.dbg.addr(metadata i32 *%something, metadata !1, metadata
!DIExpression()), !dbg !6
br i1 %cond, label %truebr, label %falsebr
bb1:
%value = phi i32 [ %value1, %truebr ], [ %value2, %falsebr ]
br label %exit, !dbg !6
truebr:
call void @llvm.dbg.value(metadata i32 1, metadata !1, metadata
!DIExpression()), !dbg !6
%value1 = add i32 %input, 1
br label %bb1
falsebr:
call void @llvm.dbg.value(metadata i32 2, metadata !1, metadata
!DIExpression()), !dbg !6
%value2 = add i32 %input, 2
br label %bb1
exit:
%wat = load i32, i32 *%something
%nou = add i32 %wat, %value
ret i32 %nou, !dbg !6
}
!llvm.module.flags = !{!4}
!llvm.dbg.cu = !{!2}
!1 = !DILocalVariable(name: "bees", scope: !5, type: !7)
!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer:
"beards", isOptimized: true, runtimeVersion: 4, emissionKind: FullDebug)
!3 = !DIFile(filename: "bees.cpp", directory: "")
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = distinct !DISubprogram(name: "nope", scope: !2, file: !3, line: 1, unit:
!2, type: !8)
!6 = !DILocation(line: 0, scope: !5)
!7 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
!8 = !DISubroutineType(types: !9)
!9 = !{!7, !7, !7}
--------8<--------</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>