Building for riscv64 fails with link errors on __thread variables.
Set -fno-emulated-tls to fix it.
Bug: 254713216
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true ndk_sysroot
Change-Id: I3dca81dfd277d681b6c868a5e8385e3a37335a5f
Building with LTO and CFI enabled for riscv64 causes link failures:
ld.lld: error: lto.tmp: cannot link object files with different floating-point ABI
ld.lld: error: undefined symbol: guard variable for android::hardware::BufferedTextOutput::getBuffer() const::ts
Disable them for now.
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true ndk_sysroot
Change-Id: I3489952abebeeb3f4de664fd3e436232aac298d7
Using a dynamic libclang_rt.ubsan_standalone runtime causes
problems when dalvikvm dlopen's libart.so:
JniInvocation E 10-19 18:25:55 1159447 1159447] Failed to dlopen libart.so: Error relocating /mnt/disks/build-disk/src/android/master/out/host/linux-x86/lib64/libclang_rt.ubsan_standalone-x86_64.so: (null): initial-exec TLS resolves to dynamic definition in /mnt/disks/build-disk/src/android/master/out/host/linux-x86/lib64/libclang_rt.ubsan_standalone-x86_64.so
This seems to be caused by a thread local variable with an
explicit initial-exec TLS model in libclang_rt.ubsan_standalone,
which is then rejected by musl's dynamic loader. Switching to
a static libclang_rt.ubsan_standalone matches what we are doing
for glibc and fixes musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true out/target/common/obj/JAVA_LIBRARIES/ahat-test-dump_intermediates/test-dump-base.hprof
Change-Id: I3e50eae6c22b684fc7bb0ccdfe0379f41d246319
unwinding through tagged frames is fixed in upstream and cherry-picked
onto Android toolchain in https://r.android.com/2251926. until then, we
can disable stack tagging for code that uses exception, so we can get
some coverage before the toolchain update.
Test: stack_tagging_helper exception_cleanup from https://r.android.com/2175188
fails with assertion "GetTag(&y) !=
GetTag(__builtin_frame_address(0))" as expected
Bug: 174878242
Change-Id: I1597b21f64a92874dbccb64ffebbef7bb9bf8214
The root cause for the warning is fixed in upstream LLVM
(https://reviews.llvm.org/D127917) , working around until
that is submitted.
Test: make libc with memtag-stack
Bug: 174878242
Change-Id: Iae8c85f39bdceb9752b7f2758c5543c1b3f90277
This change depends on the following toolchain commit:
https://reviews.llvm.org/D118948
Bug: b/174878242
Test: sanitize_test.go
Test: fvp_mini with SANITIZE_TARGET=memtag_heap,memtag_stack
Change-Id: I52d2318c8e4e06d6da5b74c45226144b880f1577
The prebuilts for musl have the necessary symbols for vptr and function
sanitizers, but enabling them implicitly enables RTTI which causes RTTI
mismatch issues with dependencies.
Bug: 215802826
Test: m USE_HOST_MUSL=true host-native
Change-Id: I93edfd617d99efcac0eca58bb3f3c173c4fa121a
Don't use hwasan for non-bionic arm64 targets, including
arm64-linux-musl and arm64 darwin.
This relands I67c07f26f25a9f9807ee21ee79c113ea11f65473 which was
accidentally reverted in I47a9322929baff2492c6e8db989ece01fcbeb133.
Bug: 236052820
Test: build arm64 musl sysroot
Change-Id: I77753ecb6f07aafa1b6e00ad6bf432f9c9744f79
Add toolchains to support cross compiling to aarch64-linux-musl and
arm-linux-musleabihf.
Bug: 236052820
Test: build arm and arm64 musl sysroots
Change-Id: I47a9322929baff2492c6e8db989ece01fcbeb133
The logic is not 100% provably the same since HEAD was quite
confusing at some points, but I did make an effort to preserve
functional equivalence.
In case that effort was not enough, it should be pretty easy to
tweak the logic at HEAD since it's still quite malleable.
Bug: 231370928
Test: Presubmits.
Change-Id: I17b2efbfb5c4d0aedd922caed54ff8d857e578df
The sanitize code was assuming that the names of the clang runtime
library modules were the same as their static library output files,
but that's not true after I39e2cf8ae14edf8510276dab38011afaef85822c.
Use the dependency to get the name of the library to pass to
-Wl,--exclude-libs.
This relands If6ca7838800c76f90105fb02d39e8a68cec96314 with a fix
for skipping tests that don't work on mac.
Bug: 235624976
Test: TestUbsan
Change-Id: I32894d10d24473ad48b6afc5663f91fa48a6a0ba
Turns out, the whole context is not needed and then let's not
plumb it any further than necessary.
Test: Presubmits.
Change-Id: I1a25738e5a6ca20dea0d973c2ce435b5e152399b
THe sanitize code was assuming that the names of the clang runtime
library modules were the same as their static library output files,
but that's not true after I39e2cf8ae14edf8510276dab38011afaef85822c.
Use the dependency to get the name of the library to pass to
-Wl,--exclude-libs.
Bug: 235624976
Test: TestUbsan
Change-Id: If6ca7838800c76f90105fb02d39e8a68cec96314
Cflag "-fsanitize-trap=all" will override "-fno-sanitize-trap=integer" if "-fsanitize-trap=all" is placed behind. Change the order to make minimal abort work, which will output the abort message to give user a better prompt.
Bug: 233840743
Test: "objdump -dS {CFI enabled so}" to check the instrumented abort instruction
Change-Id: Id85fa8ece3e13d1b21b4fdbf5f4b5124011890ca
This is so that we can avoid mutating state in sanitizerMutator, as
would be necessary if we only had a single bit for every sanitizer
together.
Test: Presubmits.
Change-Id: I5576367c12972fbea64342ab123118ec5a2cfeec
Also remove a tiny bit of state mutation from sanitizerMutator. Every
little bit helps!
Test: Prebuilts + comparing soong/build.ninja .
Your branch is up to date with 'aosp/master'.
Change-Id: I73b28b660b572610242765d87b70ab081b0b43df
Now that we provide runtimes built for musl, enable the sanitizers
when targeting musl.
Bug: 215802826
Test: m USE_HOST_MUSL=true host-native
Change-Id: Id17513ee305274874c31e9c99ce4faeff4a1c057
Previously, we use to fill memory with 0xbe bytes. This caused a lot of
problems that necessitated disablement. For example, 0xbe-filled mutexes
are apparently locked, and there were a few instances of
uninitialized-mutex use.
Given that zero-fill is now the default behaviour, enable zero-init in
HWASan as well.
For now, only fill the first page. It would be preferable to fill the
whole allocation, but I don't want to spin for too many cycles filling
huge secondary pages. In future, we might change the behaviour to have
an explicit "zero initialize" option that completely fills the primarily
allocations, and knows it's unnecessary for the secondary.
Bug: 226078464
Test: Boot w/ HWASan (done by presubmit robot)
Change-Id: I7de3a7f9fa2fdeb5116e5bf6586babe4d06fcb91
This CL enables HWASan to detect a new class of bugs, specifically
use-after-scope. An example for a bug like this is
int* y;
{
int x = 1;
y = &x;
}
*y = 2;
IF YOU FOUND THIS CL AS A POSSIBLE CULPRIT OF A TEST FAILURE:
While it is possible that there is a bug in HWASan and this CL needs
to be rolled back, please also consider that this might surface
actual problems in either the test code or the code under test. See
https://r.android.com/1956922 for an example of fix for a bug
detected by a previous rollout of this flag.
This reverts commit fd337b3963.
Reason for revert: Once https://r.android.com/1985009 is submitted the bug that caused the revert will be fixed.
Change-Id: Id9e81e8b7c26e044af00bdaeae6bb35abbbd9710
