Fix for NDK HWASan on RISC-V
We can no longer assume that because ART is not compiled with HWASan,
HWASan is not active. There could be instrumented JNI frames, so we need
to do a runtime check for whether the HWASan runtime is loaded, via a
weak symbol. This is the same we do for arm64.
Bug: 276930343
Change-Id: I7a7f85fc48a2e9f510dd5421ca3a55d6f0cce2c9
diff --git a/runtime/arch/riscv64/context_riscv64.cc b/runtime/arch/riscv64/context_riscv64.cc
index 84bd963..ae4e004 100644
--- a/runtime/arch/riscv64/context_riscv64.cc
+++ b/runtime/arch/riscv64/context_riscv64.cc
@@ -23,11 +23,7 @@
#include "quick/quick_method_frame_info.h"
#include "thread-current-inl.h"
-#if __has_feature(hwaddress_sanitizer)
-#include <sanitizer/hwasan_interface.h>
-#else
-#define __hwasan_handle_longjmp(sp)
-#endif
+extern "C" __attribute__((weak)) void __hwasan_handle_longjmp(const void* sp_dst);
namespace art {
namespace riscv64 {
@@ -144,7 +140,9 @@
gprs[TR] = reinterpret_cast<uintptr_t>(Thread::Current());
// Tell HWASan about the new stack top.
- __hwasan_handle_longjmp(reinterpret_cast<void*>(gprs[SP]));
+ if (__hwasan_handle_longjmp != nullptr) {
+ __hwasan_handle_longjmp(reinterpret_cast<void*>(gprs[SP]));
+ }
art_quick_do_long_jump(gprs, fprs);
}