summaryrefslogtreecommitdiff
path: root/lib/CodeGen/DwarfEHPrepare.cpp
diff options
context:
space:
mode:
authorBill Wendling <isanbard@gmail.com>2011-06-01 01:49:35 +0000
committerBill Wendling <isanbard@gmail.com>2011-06-01 01:49:35 +0000
commitedac4923dc2e1694f7004123ccd7c1af952d0d68 (patch)
treed5cc2ee0acefe8fdca2e4eec4d11b78f9ff79e59 /lib/CodeGen/DwarfEHPrepare.cpp
parentc20bdf194ad4c824ee6a5f163410d73513ae5c81 (diff)
downloadllvm-edac4923dc2e1694f7004123ccd7c1af952d0d68.tar.gz
llvm-edac4923dc2e1694f7004123ccd7c1af952d0d68.tar.bz2
llvm-edac4923dc2e1694f7004123ccd7c1af952d0d68.tar.xz
The ARM stuff already calls the Resume function, not the Resume_or_Rethrow. It
turns out that it could cause an infinite loop in some situations. If this code is triggered and it converts a cleanup into a catchall, but that cleanup was in already in a cleanup, then the _Unwind_SjLj_Resume could infinite loop. I.e., the code doesn't consume the exception object and passes it on to _Unwind_SjLj_Resume. But _USjLjR expects it to be consumed (since it's landing at a catchall instead of a cleanup). So it uses the values that are presently there, which are the values that tell it to jump to the fake landing pad. <rdar://problem/9508402> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132381 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/CodeGen/DwarfEHPrepare.cpp')
-rw-r--r--lib/CodeGen/DwarfEHPrepare.cpp5
1 files changed, 1 insertions, 4 deletions
diff --git a/lib/CodeGen/DwarfEHPrepare.cpp b/lib/CodeGen/DwarfEHPrepare.cpp
index 873ddd20b8..22c5465bf9 100644
--- a/lib/CodeGen/DwarfEHPrepare.cpp
+++ b/lib/CodeGen/DwarfEHPrepare.cpp
@@ -252,10 +252,7 @@ bool DwarfEHPrepare::HandleURoRInvokes() {
if (!URoR) {
URoR = F->getParent()->getFunction("_Unwind_Resume_or_Rethrow");
- if (!URoR) {
- URoR = F->getParent()->getFunction("_Unwind_SjLj_Resume");
- if (!URoR) return CleanupSelectors(CatchAllSels);
- }
+ if (!URoR) return CleanupSelectors(CatchAllSels);
}
SmallPtrSet<InvokeInst*, 32> URoRInvokes;