llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.01k stars 11.95k forks source link

Missing Variables information at Og #46437

Open 31fbadee-9e60-4c99-b908-8380e6a40c85 opened 4 years ago

31fbadee-9e60-4c99-b908-8380e6a40c85 commented 4 years ago
Bugzilla Link 47093
Version trunk
OS Linux
Blocks llvm/llvm-project#38116
CC @dwblaikie,@JDevlieghere,@jmorse,@jdm,@walkerkd,@pogo59,@vedantk

Extended Description

At line 9 lldb says that variables l_1876 and l_2441 are optimized out, but they are actually used.

$ cat -n a.c 1 short a; 2 int b, d = 4; 3 int *c = &b; 4 void func_3() { 5 int *l_1876 = &c; 6 int e = 1; 7 if (d) { 8 int l_2441 = a; 9 (*l_1876) = l_2441; 10 } 11 l_1876 = &e; 12 } 13 int main() { func_3(); }

$ cat a.c short a; int b, d = 4; int *c = &b; void func_3() { int *l_1876 = &c; int e = 1; if (d) { int l_2441 = a; (*l_1876) = l_2441; } l_1876 = &e; } int main() { func_3(); }

$ clang -v clang version 12.0.0 (https://github.com/llvm/llvm-project.git bc8be3054067ac822fc6d9f4f8e64c841f530f16) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Candidate multilib: .;@m64 Selected multilib: .;@m64

$ lldb -v lldb version 12.0.0 clang revision bc8be3054067ac822fc6d9f4f8e64c841f530f16 llvm revision bc8be3054067ac822fc6d9f4f8e64c841f530f16

$ clang -g -Og -o opt a.c

$ lldb opt (lldb) target create "opt" Current executable set to 'opt' (x86_64). (lldb) b func_3 Breakpoint 1: where = opt`func_3 at a.c:6:7, address = 0x0000000000400480 (lldb) r Process 66 launched: '/home/stepping/output/opt' (x86_64) Process 66 stopped

jmorse commented 4 years ago

To me, this sounds like something discovered in bug 39787, we're terrible at salvaging anything to do with a global symbol reference. In the reproducer, a bunch of local variables all trace back to global variables, and they all get folded into memory expressions, so never get an in-register location.

I think the biggest problem is that DBG_VALUE instructions are not expected to contain any GlobalValue operands.

It looks like GCC uses DW_OP_addr to describe most of these variables, I imagine that's the correct way, but don't know that part of DWARF well.