diff options
author | Michael Buch <michaelbuch12@gmail.com> | 2025-06-12 17:14:31 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-06-12 17:14:31 +0100 |
commit | c6da2c877cb407c0404e58c5ca257d12036ed164 (patch) | |
tree | bd3883f27154419140fe2c7550886d50ea237f12 /clang/lib/CIR/CodeGen/CIRGenModule.cpp | |
parent | daee5eee8562d26d234f85152e803b6571b15ee2 (diff) | |
download | llvm-c6da2c877cb407c0404e58c5ca257d12036ed164.zip llvm-c6da2c877cb407c0404e58c5ca257d12036ed164.tar.gz llvm-c6da2c877cb407c0404e58c5ca257d12036ed164.tar.bz2 |
[lldb][Commands] Fix memory find for Swift expressions (#143860)
(depends on https://github.com/llvm/llvm-project/pull/143686)
There were two issues previously preventing `memory find -e` expressions
to succeed when stopped in Swift frames:
1. We weren't getting the dynamic type of the result `ValueObject`.
For Swift this would fail when we tried to produce a scalar value
out of it because the static VO wasn't sufficient to get to the
integer value. Hence we add a call to
`GetQualifiedRepresentationIfAvailable`
(which is what we do for expressions in `OptionArgParser::ToAddress`
too).
2. We weren't passing an `ExecutionContextScope` to `GetByteSize`, which
Swift relied on to get the size of the result type.
My plan is to add an API test for this on the Apple
`swiftlang/llvm-project` fork.
I considered an alternative where we use `OptionArgParser::ToAddress`
for `memory find -e` expressions, but it got a bit icky when trying to
figure out how many bytes we should copy out of the result into the
`DataBufferHeap` (currently we rely on the size of the result variable
type). This gets even trickier when we were to pass an expression that
was actually a hex digit or a number into `ToAddress`.
rdar://152113525
Diffstat (limited to 'clang/lib/CIR/CodeGen/CIRGenModule.cpp')
0 files changed, 0 insertions, 0 deletions