[llvm-bugs] [Bug 43926] New: [call site info / entry values] DW_AT_call_target describes clobbered register

[via llvm-bugs]

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

            Bug ID: 43926
           Summary: [call site info / entry values] DW_AT_call_target
                    describes clobbered register
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: vsk at apple.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

When describing an indirect call, llvm may specify a clobbered register as the
call target.

Example:

```
caller:
  ...
  mov (%rdi), %rax
  callq *%rax

->

DW_TAG_call_site
  DW_AT_call_target     (DW_OP_reg0 RAX)
  DW_AT_call_return_pc  ...
```

Here, %rax is not preserved by the callee. This means that the debugger cannot
figure out the actual call target, and therefore, I believe it cannot safely
evaluate entry values in the eventual callee.

Example: `callq *%rax` may branch to `tail_calling_helper`, which can tail call
`eventual_callee`; alternatively, `callq *%rax` can branch to `eventual_callee`
immediately. The debugger simply does not know the call target, so it does not
know which function to search for call site parameter infos.

How does gcc handle this? Should llvm attempt to "work backwards" to find a
non-clobbered description of the call target (perhaps using the existing
`describeLoadedValue` API)?

-- 
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/20191107/1ac4d04a/attachment-0001.html>