summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorVitaly Buka <vitalybuka@google.com>2018-02-26 21:40:19 +0000
committerVitaly Buka <vitalybuka@google.com>2018-02-26 21:40:19 +0000
commit781ef03e10120bf3b6a0770a1832a2e7fa37c079 (patch)
treeaf1fe2e513907668f10bfe6e32b8973483455c99 /lldb/packages/Python/lldbsuite/test
parent5d3b0e38d649f0843970a689c735c803a6e98d0f (diff)
downloadbcm5719-llvm-781ef03e10120bf3b6a0770a1832a2e7fa37c079.tar.gz
bcm5719-llvm-781ef03e10120bf3b6a0770a1832a2e7fa37c079.zip
[asan] Intercept std::rethrow_exception indirectly
Summary: Fixes Bug 32434 See https://bugs.llvm.org/show_bug.cgi?id=32434 Short summary: std::rethrow_exception does not use __cxa_throw to rethrow the exception, so if it is called from uninstrumented code, it will leave the stack poisoned. This can lead to false positives. Long description: For functions which don't return normally (e.g. via exceptions), asan needs to unpoison the entire stack. It is not known before a call to such a function where execution will continue, some function which don't contain cleanup code like destructors might be skipped. After stack unwinding, execution might continue in uninstrumented code. If the stack has been poisoned before such a function is called, but the stack is unwound during the unconventional return, then zombie redzones (entries) for no longer existing stack variables can remain in the shadow memory. Normally, this is avoided by asan generating a call to asan_handle_no_return before all functions marked as [[noreturn]]. This asan_handle_no_return unpoisons the entire stack. Since these [[noreturn]] functions can be called from uninstrumented code, asan also introduces interceptor functions which call asan_handle_no_return before running the original [[noreturn]] function; for example, cxa_throw is intercepted. If a [[noreturn]] function is called from uninstrumented code (so the stack is left poisoned) and additionally, execution continues in uninstrumented code, new stack variables might be introduced and overlap with the stack variables which have been removed during stack unwinding. Since the redzones are not cleared nor overwritten by uninstrumented code, they remain but now contain invalid data. Now, if the redzones are checked against the new stack variables, false positive reports can occur. This can happen for example by the uninstrumented code calling an intercepted function such as memcpy, or an instrumented function. Intercepting std::rethrow_exception directly is not easily possible since it depends on the C++ standard library implementation (e.g. libcxx vs libstdc++) and the mangled name it produces for this function. As a rather simple workaround, we're intercepting _Unwind_RaiseException for libstdc++. For libcxxabi, we can intercept the ABI function __cxa_rethrow_primary_exception. Patch by Robert Schneider. Reviewers: kcc, eugenis, alekseyshl, vitalybuka Reviewed By: vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42644 llvm-svn: 326132
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud