[llvm-bugs] [Bug 40628] New: [DebugInfo at O2] Salvaged memory loads can observe subsequent memory writes

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40628

            Bug ID: 40628
           Summary: [DebugInfo at 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: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: aprantl at apple.com, bjorn.a.pettersson at ericsson.com,
                    chackz0x12 at gmail.com, dblaikie at gmail.com,
                    greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org, paul.robinson at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190206/ba14cec5/attachment.html>