[llvm-bugs] [Bug 38763] New: [DebugInfo][Dexter] Speculated BB presents illegal variable value to debugger

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 29 09:03:44 PDT 2018


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

            Bug ID: 38763
           Summary: [DebugInfo][Dexter] Speculated BB presents illegal
                    variable value to debugger
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: chackz0x12 at gmail.com, greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Speculating a basic block into a select IR insn causes an illegal variable
value to be presented to the debugger. Taking the code below, compiled -O2 -g
for x86_64 with trunk, on the line "if (read == 4)" both gdb and lldb report
that the value of "result" is two, where it should be zero.

The value two isn't calculated in the execution of this program, and when
compiled with -O0 "result" is correctly reported zero on that line. More
interestingly, the illegal value doesn't actually seem to be read from a
speculated instruction, "result" is reported as two from the moment the
volatile loads are done.

I get the impression that something DWARFy is going wrong, as the
DW_AT_location expression for "result" looks way more complicated that it needs
to be.

Found using DExTer ( https://github.com/SNSystems/dexter ).

-------->8--------
int
main()
{
  volatile int foo = 4;
  int read = foo;
  int read1 = foo;

  int result = 0;
  if (read == 4) {
    result = read1 + 2;
  } else {
    result = read1 - 2;
  }

  return result;
}
--------8<--------

-- 
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/20180829/530f0531/attachment.html>


More information about the llvm-bugs mailing list