search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

[call site info / entry values] DW_AT_call_target describes clobbered register #42896

Open Quuxplusone opened 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR43926
Status NEW
Importance P normal
Reported by Vedant Kumar (vsk@apple.com)
Reported on 2019-11-06 16:10:56 -0800
Last modified on 2019-11-22 07:18:43 -0800
Version trunk
Hardware PC All
CC aprantl@apple.com, david.stenberg@ericsson.com, djordje.todorovic@rt-rk.com, friss@apple.com, jdevlieghere@apple.com, jeremy.morse.llvm@gmail.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com
Fixed by commit(s)
Attachments
Blocks PR44116
Blocked by
See also

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)?

Quuxplusone commented 4 years ago

Thanks for finding this!

We should investigate that for sure, and at least remove the indirect call sites with the clobbered register.