[llvm-bugs] [Bug 51704] New: LiveDebugValues pass incorrectly handles register spill for indirect debug values

[via llvm-bugs]

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

            Bug ID: 51704
           Summary: LiveDebugValues pass incorrectly handles register
                    spill for indirect debug values
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: kosov.pavel at huawei.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Created attachment 25213
  --> https://bugs.llvm.org/attachment.cgi?id=25213&action=edit
Archive contains build script, source files and gdb commands for reproducing
this bug

When handling register spill for indirect debug value LiveDebugValues pass
doesn't add
DW_OP_deref operator which may in some cases cause debugger to return value
address, instead
of value while machine register holding that address is spilled.

Attached file contains reproducer for this issue, which is actualy made from
one of LLVM
integration tests (DebugInfo/MIR/X86/live-debug-values-restore.mir). To
reproduce:

- compile the sample with build.sh script from the attached archive
- invoke gdb with command file: gdb -x gdb-commands.txt ldv-indir-test

You should see something like following in the output:

```
Breakpoint 2, 0x00000000002018df in j (t=274877906976) at test2.c:106
106     test2.c: No such file or directory.
1: x/3i $pc
=> 0x2018df <j+15>:     mov    %rdi,-0x8(%rsp)
   0x2018e4 <j+20>:     mov    -0x8(%rsp),%rdi
   0x2018e9 <j+25>:     pop    %rbx
(gdb) p/x t
$1 = 0x4000000020
(gdb) si
107     in test2.c
1: x/3i $pc
=> 0x2018e4 <j+20>:     mov    -0x8(%rsp),%rdi
   0x2018e9 <j+25>:     pop    %rbx
   0x2018ea <j+26>:     pop    %r12
(gdb) p/x t
$2 = 0x7fffffffd894
```

So the value of t ($1) changes to ($2) while t's address (%rdi) is spilled
to -0x8(%rsp).

If you look at DW_AT_location entries for `t` you can see why this happens:

```
DW_TAG_formal_parameter
  DW_AT_location        (0x00000181:
         [0x00000000002018a3, 0x00000000002018b7): DW_OP_breg5 RDI+0
         [0x00000000002018b7, 0x00000000002018bc): DW_OP_breg7 RSP-8
         [0x00000000002018bc, 0x00000000002018ca): DW_OP_breg5 RDI+0)
  DW_AT_name    ("t")
```

The second location entry (RSP-8) is created without DW_OP_deref, so debugger
shows an address instead of value.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210901/89b6964d/attachment.html>