https://bugs.llvm.org/show_bug.cgi?id=40628
Bug ID: 40628
Summary: [DebugInfo@O2] Salvaged memory loads can observe
subsequent memory writes
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: CONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: apra...@apple.com, bjorn.a.petters...@ericsson.com,
chackz0...@gmail.com, dblai...@gmail.com,
greg.bedw...@sony.com,
international.phan...@gmail.com,
llvm-bugs@lists.llvm.org, paul.robin...@am.sony.com
Blocks: 38768
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] https://reviews.llvm.org/D56788
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
