[lldb-dev] [Bug 50076] New: lldb doesn't find locationless variables in abstract origin of inlined functions

[via lldb-dev]

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

            Bug ID: 50076
           Summary: lldb doesn't find locationless variables in abstract
                    origin of inlined functions
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: cristianassaiante at outlook.com, dblaikie at gmail.com,
                    jdevlieghere at apple.com, llvm-bugs at lists.llvm.org

Hi lldb folks,

I believe lldb isn't "seeing" variables that appear only in the abstract
origins of DW_TAG_inlined_subroutines. Over in https://reviews.llvm.org/D95617
we started omitting variables that have no location, i.e. never emitting things
like:

      DW_TAG_formal_parameter
             DW_AT_abstract_origin       (0x0000005a "bar")

by themselves, instead expecting the consumer to look in the
DW_TAG_inlined_subroutine's abstract origin for it. It appears that lldb
doesn't do this, while gdb does. Specifically, if you take the reproducer for
bug 49973 and revert D95617, lldb produces different error messages when it
can't find an optimised out variable, here's a long script:

$ clang --version
clang version 13.0.0 (git at github.com:llvm/llvm-project
e6eaacbf0bd0c76a4fbfbd30c6159f57a89b3480)
Target: x86_64-unknown-linux-gnu

$ clang -o a.out -g -O3 lib/test.c a.c
[some warnings]

$ lldb --version
lldb version 13.0.0 (git at github.com:llvm/llvm-project revision
e6eaacbf0bd0c76a4fbfbd30c6159f57a89b3480)
  clang revision e6eaacbf0bd0c76a4fbfbd30c6159f57a89b3480
  llvm revision e6eaacbf0bd0c76a4fbfbd30c6159f57a89b3480

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/tmp/faces/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 [inlined] c + 10 at a.c:9:1, address =
0x000000000040056b
(lldb) process launch
Process 14037 launched: '/tmp/faces/a.out' (x86_64)
Process 14037 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x000000000040056b a.out`main [inlined] c at a.c:9:1
   6    int l_128 = b = 4;
   7    for (; b ; b = 0)
   8    l_128 = 1;
-> 9    test_nop();
   10   test_support_3008(l_128);
   11   }
   12   int main ()
(lldb) p l_128
error: <user expression 0>:1:1: use of undeclared identifier 'l_128'
l_128
^
(lldb) ^D

$ git revert 1d68e0a0756476ceee1e62a778021e339c631940

$ ninja ./bin/clang ./bin/opt ./bin/llc ./bin/lldb

$ clang -o a.out -g -O3 lib/test.c a.c
[some warnings]

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/tmp/faces/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 [inlined] c + 10 at a.c:9:1, address =
0x000000000040056b
(lldb) process launch
Process 14683 launched: '/tmp/faces/a.out' (x86_64)
Process 14683 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x000000000040056b a.out`main [inlined] c at a.c:9:1
   6    int l_128 = b = 4;
   7    for (; b ; b = 0)
   8    l_128 = 1;
-> 9    test_nop();
   10   test_support_3008(l_128);
   11   }
   12   int main ()
(lldb) print l_128
error: Couldn't materialize: couldn't get the value of variable l_128: no
location, value may have been optimized out
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb)

~

tl;dr: lldb produces "value may have been optimized out" before D95617 lands,
"undeclared identifier" afterwards. gdb produces "optimized out" in all
scenarios.

We were pretty confident in
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148165.html that the
DWARF is fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210422/15f6c305/attachment.html>