aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/TextAPI/Architecture.cpp
diff options
context:
space:
mode:
authorJann <jannh@google.com>2025-08-05 22:25:01 +0200
committerGitHub <noreply@github.com>2025-08-05 13:25:01 -0700
commitda6424c9e307cd324f37745b525d3884b5077707 (patch)
tree8a59037c50d093d827e9b45165eab8b623f969ec /llvm/lib/TextAPI/Architecture.cpp
parent97dee3244535b4bc6cfb65a1dfa8f3ae93bd5752 (diff)
downloadllvm-da6424c9e307cd324f37745b525d3884b5077707.zip
llvm-da6424c9e307cd324f37745b525d3884b5077707.tar.gz
llvm-da6424c9e307cd324f37745b525d3884b5077707.tar.bz2
[DebugInfo][DWARF] Don't emit bogus DW_AT_call_target for complex calls (#151378)
On X86-64, LLVM currently generates the same DWARF debug info for `call rax` and `call [rax]`; in both cases, the generated DWARF claims that the call goes to address RAX. This bug occurs because the X86 machine instructions CALL64r and CALL64m both receive register operands, but those register operands have different semantics. To fix it, change DwarfDebug::constructCallSiteEntryDIEs() to validate the callee operand's semantics (`OperandType`) and make sure it is not semantically describing a memory location. This fix will result in less DW_TAG_call_site and DW_AT_call_target entries being generated. There is an existing test in dwarf-callsite-related-attrs.ll that asserts the broken behavior; remove the broken check, and instead add a new test dwarf-callsite-related-attrs-indirect.ll that checks behavior for indirect calls. The existing test xray-custom-log.ll is validating something even more broken: It checks the debug info generated by a PATCHABLE_EVENT_CALL. `TII->getCalleeOperand()` assumes that the first argument of a call instruction is always the destination, but the first argument of PATCHABLE_EVENT_CALL is instead the event structure; and so we were emitting debug info claiming the callee was stored in a register that actually contains some kind of xray event descriptor, and the test validates that this happens. I am breaking and deleting this test. I guess the intent there might have been to validate that we emit debuginfo referencing the target of the direct call that LLVM emits (which we don't do)? But I'm not sure.
Diffstat (limited to 'llvm/lib/TextAPI/Architecture.cpp')
0 files changed, 0 insertions, 0 deletions