Some of the ubsan checks expose a few pathological performance cases
in clang, and thus aren't suited to be used in SANITIZE_HOST.
This mode is also supported on the target despite not having the
target runtime libraries for ubsan by generating traps.
Change-Id: I0b0f0a08ca84d72e44e2174a66726b1c5e5cad7e
Ying pointed out in https://android-review.googlesource.com/#/c/147290
that my_sanitize_host would be read as some garbage value for target
builds. Move the configuration later and don't use the local at all.
Change-Id: Id8a095821d000a184e72f950b9481597073a7044
Previously using a sanitizer would imply clang. It should be an error
instead so it's more obvious.
Change-Id: I67c949bfda3718a0d19da7e358b5fde447fce334
* Refactor a few pieces to avoid deeply nested conditionals.
* LOCAL_SANITIZE := never replaces LOCAL_ADDRESS_SANITIZER := false.
Change-Id: I68bb8c5edda6ecd40179c5ba9f18d06e96aaa260
Rather than adding LOCAL_UB_SANITIZER, LOCAL_THREAD_SANITIZER, etc for
each new sanitizer, deprecate LOCAL_ADDRESS_SANITIZER in favor of
LOCAL_SANITZE that mirrors the behavior of -fsanitize=<sanitizers>.
For example, the following will use both asan and ubsan:
LOCAL_SANITIZE := address undefined
We'll leave LOCAL_ADDRESS_SANITIZER around for compatibility until we
can clean up the tree.
Change-Id: I8a62315129d4753f8e992584ca6db1e5dfdd4d2a
We had discussed the idea of making all host tools default to using
ASAN. Even if we don't make it the default, this makes it easy for the
user to switch all host binaries over.
Change-Id: I64a5c741b1b4e9aefed3a6be8dcd4f386e06b29c
Dan Albert