aboutsummaryrefslogtreecommitdiff
path: root/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
diff options
context:
space:
mode:
authorJeremy Morse <jeremy.morse@sony.com>2021-07-27 13:15:42 +0100
committerJeremy Morse <jeremy.morse@sony.com>2021-07-27 13:44:37 +0100
commit7dc9d7373186827a92d6ca08ad7192208dfea389 (patch)
treefb2e66e2f18187507c6282a6b18df4f9d7c81308 /lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
parent1930c4410d6b48645b7b7c58cf4403a2a0e3836d (diff)
downloadllvm-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