diff options
author | Jann <jannh@google.com> | 2025-08-05 22:25:01 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-08-05 13:25:01 -0700 |
commit | da6424c9e307cd324f37745b525d3884b5077707 (patch) | |
tree | 8a59037c50d093d827e9b45165eab8b623f969ec /llvm/lib/TextAPI/Architecture.cpp | |
parent | 97dee3244535b4bc6cfb65a1dfa8f3ae93bd5752 (diff) | |
download | llvm-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