<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_CONFIRMED "
title="CONFIRMED - [DebugInfo@O2] Salvaged memory loads can observe subsequent memory writes"
href="https://bugs.llvm.org/show_bug.cgi?id=40628">40628</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[DebugInfo@O2] Salvaged memory loads can observe subsequent memory writes
</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>CONFIRMED
</td>
</tr>
<tr>
<th>Keywords</th>
<td>wrong-debug
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Scalar Optimizations
</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, dblaikie@gmail.com, greg.bedwell@sony.com, international.phantom@gmail.com, llvm-bugs@lists.llvm.org, paul.robinson@am.sony.com
</td>
</tr>
<tr>
<th>Blocks</th>
<td>38768
</td>
</tr></table>
<p>
<div>
<pre>In this [0] review Bjorn suggested that introducing new dbg.value records that
use DW_OP_deref might be sketchy (see inline comments). It turns out that
adding DW_OP_deref is indeed unsafe, and already leads to poor debug experience
on trunk (I'm using r352480). Compile the following with -O2 -g -fno-linine:
--------8<--------
int
foo(int *bar, int arg, int more)
{
int redundant = *bar;
int loaded = *bar;
arg &= more + loaded;
*bar = 0;
return more + *bar;
}
int
main() {
int lala = 987654;
return foo(&lala, 1, 2);
}
-------->8--------
Here, the two loads of *bar get CSE'd and "redundant" is salvaged. It picks up
a DW_OP_deref to achieve this. There are two line numbers in "foo" that one can
step onto with gdb: "*bar = 0" and the return statement. On the first, printing
"redundant" produces 987654, on the second printing "redundant" produces 0.
This isn't an accurate representation of the original program as the value of
redundant should not change.
Off the top of my head I can't see any way to fix salvage operations that add
DW_OP_deref: while we could terminate the location range to stop at the next
write to memory, I doubt any LLVM passes that move memory instructions
currently examine what intervening dbg.values do, meaning there's a risk of
dbg.values seeing the wrong stored value if stores get moved.
IMHO the easiest quickest soundest fix is to not salvage such instructions:
doing so on a clang-3.4 build gives a 1.1% drop in variable location coverage
and 1% drop in scope bytes coverage. This would suck quite considerably,
however AFAIK there are currently no guard-rails for this kind of DIExpression.
[0] <a href="https://reviews.llvm.org/D56788">https://reviews.llvm.org/D56788</a></pre>
</div>
</p>
<div id="referenced">
<hr style="border: 1px dashed #969696">
<b>Referenced Bugs:</b>
<ul>
<li>
[<a class="bz_bug_link
bz_status_NEW "
title="NEW - [meta][DebugInfo] Umbrella bug for poor debug experiences"
href="https://bugs.llvm.org/show_bug.cgi?id=38768">Bug 38768</a>] [meta][DebugInfo] Umbrella bug for poor debug experiences
</li>
</ul>
</div>
<br>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>