<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 - LiveDebugVariables removes all DBG_VALUE undef, ..."
href="https://bugs.llvm.org/show_bug.cgi?id=36579">36579</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>LiveDebugVariables removes all DBG_VALUE undef, ...
</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>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>DebugInfo
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>aprantl@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Via <a href="https://reviews.llvm.org/D43956#1025531">https://reviews.llvm.org/D43956#1025531</a>, found by Björn Pettersson!
But maybe it is a bug that LiveDebugVariables removes all DBG_VALUE undef, ...?
I think it is.
If you compile the function at -O1 (to force the constant to be described with
a dbg.value)
void foo() {
// single basic block
int x = 42;
bar();
x = 23;
bar();
}
and replace the second dbg.value with a dbg.value(undef) in the LLVM IR and run
it through llc, do we get the range of the constant 42 correct in the resulting
location list for x? Does it end before the second call to bar()?
Nope, if I do that the DBG_VALUE is removed by LiveDebugVariables. And we no
longer get a .debug_loc range for "x". Instead we get
.byte 3 # Abbrev [3] 0x3f:0xc DW_TAG_variable
.byte 42 # DW_AT_const_value
.long .Linfo_string4 # DW_AT_name
.byte 1 # DW_AT_decl_file
.byte 5 # DW_AT_decl_line
.long 76 # DW_AT_type
So "x" will appear as being 42 throughout the function.
I think the right way forward would be to fix LiveDebugVariables to not drop
undef DBG_VALUEs. This will be slightly more expensive in terms of compile time
and size of the debug info (since we now need to use location lists for cases
like the one you found), but it will be far more accurate.</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>