Wrong debug info generated at -O2 (-O0 is correct)

[helloqirun]

Bugzilla Link	43893
Resolution	FIXED
Resolved on	Nov 07, 2019 17:32
Version	unspecified
OS	All
Blocks	#38116
CC	@adrian-prantl,@dwblaikie,@jmorse,@jdm,@kamleshbhalui,@pogo59,@zygoloid

Extended Description

The expected output from lldb should be -1. However, compiled with "-O2", lldb outputs -8.

$ clang-trunk -v
clang version 10.0.0 (trunk 375507)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

$ clang-trunk -g abc.c -O2
$ lldb-trunk -s cmds -batch a.out
(lldb) b 5
Breakpoint 1: where = a.out`main + 7 at abc.c:6:1, address = 0x0000000000400487
(lldb) r
Process 12592 stopped

• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000400487 a.out`main at abc.c:6:1
  3 int b = --a, l_1240 = -8L;
  4 l_1240 = b;
  5 b > 0; // optimize_me_not
  -> 6 }

Process 12592 launched: '/home/absozero/projects/LLDB-testing/reduce/a.out' (x86_64)
(lldb) p l_1240
(int) $0 = -8

$ clang-trunk -g abc.c
$ lldb-trunk -s cmds -batch a.out
(lldb) b 5
Breakpoint 1: where = a.out`main + 42 at abc.c:6:1, address = 0x00000000004004aa
(lldb) r
Process 12562 stopped

• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x00000000004004aa a.out`main at abc.c:6:1
  3 int b = --a, l_1240 = -8L;
  4 l_1240 = b;
  5 b > 0; // optimize_me_not
  -> 6 }

Process 12562 launched: '/home/absozero/projects/LLDB-testing/reduce/a.out' (x86_64)
(lldb) p l_1240
(int) $0 = -1

$ cat abc.c
char a;
int main() {
int b = --a, l_1240 = -8;
l_1240 = b;
b > 0; // optimize_me_not
}

$ cat cmds
b 5
r
p l_1240
kill
q

[helloqirun]

assigned to @kamleshbhalui

[helloqirun]

I noticed that in the above test case, the breakpoint was set at line 5 and lldb stopped at line 6.

Below, please see the same test case such that lldb stops at line 5 (and breakpoint was at line 5).

$ cat abc.c
char a, b;
int main() {
int c = --a, l_1240 = -8L;
l_1240 = c;
c > (b = 0); // optimize_me_not0
}

$ cat cmds
b 5
r
p l_1240
kill
q

$ lldb-trunk -s cmds -batch a.out
(lldb) b 5
Breakpoint 1: where = a.out`main + 7 at abc.c:5:10, address = 0x0000000000400487
(lldb) r
Process 28371 stopped

• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000400487 a.out`main at abc.c:5:10
  2 int main() {
  3 int c = --a, l_1240 = -8L;
  4 l_1240 = c;
  -> 5 c > (b = 0); // optimize_me_not0
  6 }

Process 28371 launched: '/home/absozero/projects/LLDB-testing/reduce/a.out' (x86_64)
(lldb) p l_1240
(int) $0 = -8

[jmorse]

Looking at the IR, the most of the computations are dropped by instcombine because they're unused, and so is the dbg.value inst recording "l_1240 = b". It should have be left as an undef dbg.value.

[pogo59]

I noticed that in the above test case, the breakpoint was set at line 5 and
lldb stopped at line 6.

Below, please see the same test case such that lldb stops at line 5 (and
breakpoint was at line 5).

The case where lldb did not stop at line 5 has the source:

b > 0;  //  optimize_me_not

The case where it does stop has the source:

c > (b = 0); //  optimize_me_not0

Note that the first case is a comparison whose result is not used, and
so all instructions for the line would be optimized away. That is,
there are no instructions tagged with line 5.
Note that the second case includes an assignment to 'b' and so would
not be optimized away. That is, there will be one or more instructions
tagged with line 5.

That's why lldb will stop at line 5 in the second example.

[llvmbot]

Looking at the IR, the most of the computations are dropped by instcombine
because they're unused, and so is the dbg.value inst recording "l_1240 = b".
It should have be left as an undef dbg.value.

Are you going to write a patch for this?

[kamleshbhalui]

Looking at the IR, the most of the computations are dropped by instcombine
because they're unused, and so is the dbg.value inst recording "l_1240 = b".
It should have be left as an undef dbg.value.

Are you going to write a patch for this?

Davide,
I am working on this, soon will upload it for review.

[kamleshbhalui]

review at https://reviews.llvm.org/D69809