[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