aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
diff options
context:
space:
mode:
authorDavid Majnemer <david.majnemer@gmail.com>2015-02-25 21:13:37 +0000
committerDavid Majnemer <david.majnemer@gmail.com>2015-02-25 21:13:37 +0000
commite1bbad9eb2eababecc21ace975bb25129891da38 (patch)
tree80aa5ae77b05c016172f75c23f697ba8a440ac89 /lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
parent0db567f2adf7cc3bf7cfba39817245bb245c6f1f (diff)
downloadllvm-e1bbad9eb2eababecc21ace975bb25129891da38.zip
llvm-e1bbad9eb2eababecc21ace975bb25129891da38.tar.gz
llvm-e1bbad9eb2eababecc21ace975bb25129891da38.tar.bz2
X86, Win64: Allow 'mov' to restore the stack pointer if we have a FP
The Win64 epilogue structure is very restrictive, it permits a very small number of opcodes and none of them are 'mov'. This means that given: mov %rbp, %rsp pop %rbp The mov isn't the epilogue, only the pop is. This is problematic unless a frame pointer is present in which case we are free to do whatever we'd like in the "body" of the function. If a frame pointer is present, unwinding will undo the prologue operations in reverse order regardless of the fact that we are at an instruction which is reseting the stack pointer. llvm-svn: 230543
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp')
0 files changed, 0 insertions, 0 deletions