[lldb-dev] [Bug 43126] New: [lldb] Print command reports incorrect struct field value

[via lldb-dev]

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

            Bug ID: 43126
           Summary: [lldb] Print command reports incorrect struct field
                    value
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: orlando.hyams at sony.com
                CC: jdevlieghere at apple.com, llvm-bugs at lists.llvm.org

Created attachment 22433
  --> https://bugs.llvm.org/attachment.cgi?id=22433&action=edit
bug reproducer

Summary:
lldb is reporting a local struct field as '0' when the correct value (200) has
not been described by any DWARF after compiling the attachment 'bug.cpp' at O2.

This bug was found using dexter[0].
llvm (lldb and clang) version this bug was reported with*:
   git 91824678868
   svn 369769

*not necessarily when it was introduced.

With the attached test case, variable basket.bananas is incorrectly
reported as '0' between lines [22, 25] when compiled at O2:

```
$ clang -g -O2 bug.cpp
$ lldb a.out

(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b foo
Breakpoint 1: where = a.out`foo(Box const&) + 1 at bug.cpp:18:19, address =
0x0000000000400491
(lldb) b 22
Breakpoint 2: where = a.out`foo(Box const&) + 16 at bug.cpp:22:3, address =
0x00000000004004a0
(lldb) b 25
Breakpoint 3: where = a.out`foo(Box const&) + 26 at bug.cpp:25:3, address =
0x00000000004004aa
(lldb) process launch
Process 22427 launched: 'a.out' (x86_64)
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400491 a.out`foo(box=0x00007fffffffe038) at
bug.cpp:18:19
   15   __attribute__((noinline))
   16   void foo(const Box& box)
   17   {
-> 18     Basket basket = box.baskets[2];
   19     do_something(basket.apples); // DexLabel('a')
   20   
   21     basket.apples = 55;
(lldb) p box
(const Box) $0 = {
  baskets = {
    [0] = (apples = 1, bananas = 2)
    [1] = (apples = 10, bananas = 20)
    [2] = (apples = 100, bananas = 200)
  }
}
(lldb) c
Process 22427 resuming
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
    frame #0: 0x00000000004004a0 a.out`foo(box=<unavailable>) at bug.cpp:22:3
   19     do_something(basket.apples); // DexLabel('a')
   20   
   21     basket.apples = 55;
-> 22     do_something(basket.apples); // DexLabel('b')
   23   
   24     basket.apples = basket.bananas;
   25     do_something(basket.apples); // DexLabel('c')
(lldb) p basket
(Basket) $1 = (apples = 55, bananas = 0)
(lldb) c
Process 22427 resuming
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 3.1
    frame #0: 0x00000000004004aa a.out`foo(box=<unavailable>) at bug.cpp:25:3
   22     do_something(basket.apples); // DexLabel('b')
   23   
   24     basket.apples = basket.bananas;
-> 25     do_something(basket.apples); // DexLabel('c')
   26   }
   27   
   28   
(lldb) p basket
(Basket) $2 = (apples = 55, bananas = 0)

```

The DWARF doesn't describe basket.bananas at all. The only reference to basket
is as follows:
```
$ llvm-dwarfdump --name=basket a.out
a.out:  file format ELF64-x86-64

0x00000087: DW_TAG_variable
              DW_AT_location    (0x00000023
                 [0x00000000004004a0,  0x00000000004004af): DW_OP_constu 0x37,
DW_OP_stack_value, DW_OP_piece 0x2)
              DW_AT_name        ("basket")
              DW_AT_decl_file   ("bug.cpp")
              DW_AT_decl_line   (18)
              DW_AT_type        (0x000000ff "Basket")
```

The actual value of basket.bananas is 200 (as shown in the lldb session above
with command 'p box').

Given that the dwarf doesn't describe the basket.bananas at all I would expect
basket.bananas to be shown as 'optimized away' or something similar. However it
is handled it should not be showing '0'.

gdb says that basket.bananas is a 'synthetic pointer'. I'm not sure exactly
what this means or if it is the correct message for this scenario, but I
thought it was worth mentioning.

[0]: https://github.com/SNSystems/dexter

-- 
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/20190827/627a8eb1/attachment-0001.html>