diff options
author | Jeremy Morse <jeremy.morse@sony.com> | 2021-07-27 13:15:42 +0100 |
---|---|---|
committer | Jeremy Morse <jeremy.morse@sony.com> | 2021-07-27 13:44:37 +0100 |
commit | 7dc9d7373186827a92d6ca08ad7192208dfea389 (patch) | |
tree | fb2e66e2f18187507c6282a6b18df4f9d7c81308 /lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp | |
parent | 1930c4410d6b48645b7b7c58cf4403a2a0e3836d (diff) | |
download | llvm-7dc9d7373186827a92d6ca08ad7192208dfea389.zip llvm-7dc9d7373186827a92d6ca08ad7192208dfea389.tar.gz llvm-7dc9d7373186827a92d6ca08ad7192208dfea389.tar.bz2 |
[DebugInfo][InstrRef] Handle llvm.frameaddress intrinsics gracefully
When working out which instruction defines a value, the
instruction-referencing variable location code has a few special cases for
physical registers:
* Arguments are never defined by instructions,
* Constant physical registers always read the same value, are never def'd
This patch adds a third case for the llvm.frameaddress intrinsics: you can
read the framepointer in any block if you so choose, and use it as a
variable location, as shown in the added test.
This rather violates one of the assumptions behind instruction referencing,
that LLVM-ir shouldn't be able to read from an arbitrary register at some
arbitrary point in the program. The solution for now is to just emit a
DBG_PHI that reads the register value: this works, but if we wanted to do
something clever with DBG_PHIs in the future then this would probably get
in the way. As it stands, this patch avoids a crash.
Differential Revision: https://reviews.llvm.org/D106659
Diffstat (limited to 'lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp')
0 files changed, 0 insertions, 0 deletions