aboutsummaryrefslogtreecommitdiff
path: root/lldb/scripts/Python/edit-swig-python-wrapper-file.py
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
commit48581a64547a14475cf3ba7c9ccc1f073d081e6e (patch)
tree6f03d7742adc17ae657be7485773ead3d1642480 /lldb/scripts/Python/edit-swig-python-wrapper-file.py
parent9978c4f7307bc2c0360fc0badf88c3ed9122f391 (diff)
downloadllvm-48581a64547a14475cf3ba7c9ccc1f073d081e6e.zip
llvm-48581a64547a14475cf3ba7c9ccc1f073d081e6e.tar.gz
llvm-48581a64547a14475cf3ba7c9ccc1f073d081e6e.tar.bz2
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> llvm-svn: 132381
Diffstat (limited to 'lldb/scripts/Python/edit-swig-python-wrapper-file.py')
0 files changed, 0 insertions, 0 deletions