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

[llvmbot]

Bugzilla Link	46006
Resolution	FIXED
Resolved on	May 28, 2020 07:51
Version	trunk
OS	Linux
Blocks	#38116
Reporter	LLVM Bugzilla Contributor
CC	@JDevlieghere,@jmorse,@jdm,@walkerkd,@pogo59,@vedantk

Extended Description

lldb outputs 0 when the program is compiled with "-O3". It behaves correctly when the program is compiled with "-O0".

$ cat small.c
void foo(int *a) {
(*a)++;
}

int main() {
int a = 0;
foo (&a);
return 0;
}

$ cat cmds
b 8
r
p a

$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project 871beba)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ lldb --version
lldb version 11.0.0
clang revision 871beba
llvm revision 871beba

$ clang -g -O0 small.c
$ lldb -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/yibiao/Debugger/cmds'.
(lldb) b 8
Breakpoint 1: where = a.out`main + 33 at small.c:8:3, address = 0x0000000000401151
(lldb) r
Process 3458 stopped

• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000401151 a.out`main at small.c:8:3
  5 int main() {
  6 int a = 0;
  7 foo (&a);
  -> 8 return 0;
  9 }

Process 3458 launched: '/home/yibiao/Debugger/a.out' (x86_64)
(lldb) p a
(int) $0 = 1

$ clang -g -O3 small.c
$ lldb -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/yibiao/Debugger/cmds'.
(lldb) b 8
Breakpoint 1: where = a.out`main at small.c:8:3, address = 0x0000000000401120
(lldb) r
Process 3563 stopped

• thread #​1, name = 'a.out', stop reason = breakpoint 1.1
  frame #​0: 0x0000000000401120 a.out`main at small.c:8:3
  5 int main() {
  6 int a = 0;
  7 foo (&a);
  -> 8 return 0;
  9 }

Process 3563 launched: '/home/yibiao/Debugger/a.out' (x86_64)
(lldb) p a
(int) $0 = 0

[jmorse]

Definitely a bug, the store to 'a' is identified as dead, and the value deleted in SROA/mem2reg, leaving behind an empty dbg.value. By chance, it's fixed by this patch which should land soon: https://reviews.llvm.org/D80264

This:

call void @​llvm.dbg.value(metadata i32 0,
store i32 0, i32* %a, align 4, !dbg !​15, !tbaa !​16
call void @​llvm.dbg.value(metadata i32* %a, [deref later]
call void @​llvm.dbg.value(metadata i32* %a, [deref later]

Was becoming:

call void @​llvm.dbg.value(metadata i32 0,
call void @​llvm.dbg.value(metadata !​2,
call void @​llvm.dbg.value(metadata !​2,

Where !​2 is empty metadata. With the patch, there is no location for "a" at all, which I believe is correct: the only instructions in main are to return zero.

(Sticking this into the "bad debug experience" list -- IMO this is a dexter test candidate when we get around to it. As far as I understand it, we have little testing for information being deleted correctly, as we've mostly focused on information being preserved correctly).

[vedantk]

The proximate issue should be fixed now that D80264 has landed. Would it be useful to keep this bug open to track adding a dexter test?

[jmorse]

Vedant wrote:

Would it be useful to keep this bug open to track adding a dexter test?

I was planning on harvesting them from closed bugs that were attached to the poor-debug-experience umbrella ticket, so there's no need to keep it open.

(Generating Dexter tests from past defects is still a bit more aspirational than reality, but collating these under the umbrella bug is going to ease making it reality)