The main problem here is that `-*-version_min=` was not being passed to
the compiler when building test cases. This can cause problems when
testing on devices running older OSs because Clang would previously
assume the minimum deployment target is the the latest OS in the SDK
which could be much newer than what the device is running.
Previously the generated value looked like this:
`-arch arm64 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
With this change it now looks like:
`-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
This mirrors the setting of config.target_cflags on macOS.
This change is made for ASan, LibFuzzer, TSan, and UBSan.
To implement this a new `get_test_cflags_for_apple_platform()` function
has been added that when given an Apple platform name and architecture
returns a string containing the C compiler flags to use when building
tests. This also calls a new helper function `is_valid_apple_platform()`
that validates Apple platform names.
This is the third attempt at landing the patch.
The first attempt (r359305) had to be reverted (r359327) due to a buildbot
failure. The problem was that calling `get_test_cflags_for_apple_platform()`
can trigger a CMake error if the provided architecture is not supported by the
current CMake configuration. Previously, this could be triggered by passing
`-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were
generating test configurations for a list of architectures without checking if
the relevant Sanitizer actually supported that architecture. We now intersect
the list of architectures for an Apple platform with
`<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to
iterate through the correct list of architectures.
The second attempt (r363633) had to be reverted (r363779) due to a build
failure. The failed build was using a modified Apple toolchain where the iOS
simulator SDK was missing. This exposed a bug in the existing UBSan test
generation code where it was assumed that `COMPILER_RT_ENABLE_IOS` implied that
the toolchain supported both iOS and the iOS simulator. This is not true. This
has been fixed by using the list `SANITIZER_COMMON_SUPPORTED_OS` for the list
of supported Apple platforms for UBSan. For consistency with the other
Sanitizers we also now intersect the list of architectures with
UBSAN_SUPPORTED_ARCH.
rdar://problem/50124489
Differential Revision: https://reviews.llvm.org/D61242
llvm-svn: 373405
Revert "compiler-rt: move all __GLIBC_PREREQ into own header file"
"move all __GLIBC_PREREQ" breaks build on some bots
This reverts commit 2d75ee9373.
This reverts commit 7a6461fcc2.
llvm-svn: 373367
Summary:
It's needed to use __GLIBC_PREREQ from <features.h>
tsan didn't let us to include <features.h> by using --sysroot=. to disable system includes on
anything that is not named as "tsan*posix*", "tsan*mac*", "tsan*linux*".
See compiler-rt/lib/tsan/CMakeLists.txt
Reviewers: eugenis, dvyukov, kcc
Reviewed By: kcc
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68176
llvm-svn: 373282
Summary:
This interceptor is useful on its own, but the main purpose of this
change is to intercept libpthread initialization on linux/glibc in
order to run __msan_init before any .preinit_array constructors.
We used to trigger on pthread_initialize_minimal -> getrlimit(), but
that call has changed to __getrlimit at some point.
Reviewers: vitalybuka, pcc
Subscribers: jfb, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68168
llvm-svn: 373239
This test remains flaky everywhere, I think. We should consider deleting
it and accompanying support code in GCOVProfiling: I've stopped short of
doing that now as the gcov exec* tests appear to be stable.
See the thread re: r347779.
llvm-svn: 373121
We can't use short granules with stack instrumentation when targeting older
API levels because the rest of the system won't understand the short granule
tags stored in shadow memory.
Moreover, we need to be able to let old binaries (which won't understand
short granule tags) run on a new system that supports short granule
tags. Such binaries will call the __hwasan_tag_mismatch function when their
outlined checks fail. We can compensate for the binary's lack of support
for short granules by implementing the short granule part of the check in
the __hwasan_tag_mismatch function. Unfortunately we can't do anything about
inline checks, but I don't believe that we can generate these by default on
aarch64, nor did we do so when the ABI was fixed.
A new function, __hwasan_tag_mismatch_v2, is introduced that lets code
targeting the new runtime avoid redoing the short granule check. Because tag
mismatches are rare this isn't important from a performance perspective; the
main benefit is that it introduces a symbol dependency that prevents binaries
targeting the new runtime from running on older (i.e. incompatible) runtimes.
Differential Revision: https://reviews.llvm.org/D68059
llvm-svn: 373035
ld64 in the macOS 10.15 SDK gives __DATA a maxprot of 3, meaning it
can't be made executable at runtime by default.
Change clear_cache_test.c to use mmap()ed data that's mapped as writable
and executable from the beginning, instead of trying to mprotect()ing a
__DATA variable as executable. This fixes the test on macOS with the
10.15 SDK.
PR43407.
Differential Revision: https://reviews.llvm.org/D67929
llvm-svn: 372849
Adding annotation function variants __tsan_write_range_pc and
__tsan_read_range_pc to annotate ranged access to memory while providing a
program counter for the access.
Differential Revision: https://reviews.llvm.org/D66885
llvm-svn: 372730
Differential Revision: https://reviews.llvm.org/D67937
M lib/builtins/fp_add_impl.inc
M lib/builtins/fp_lib.h
M lib/builtins/fp_trunc_impl.inc
llvm-svn: 372684
This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )
The fix is generated by running clang-format on the error lines only.
llvm-svn: 372511
Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.
This is a case when a leak on exit(3) is expected, unavoidable and harmless.
Reviewers: joerg, vitalybuka, dvyukov, mgorny
Reviewed By: vitalybuka
Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67337
llvm-svn: 372461
Summary:
The atexit(3) and __cxa_atexit() calls allocate internally memory and free on exit,
after executing all callback. This causes false positives as DoLeakCheck() is called
from the atexit handler. In the LSan/ASan tests there are strict checks triggering
false positives here.
Intercept all atexit(3) and __cxa_atexit() calls and disable LSan when calling the
real functions.
Stop tracing allocations in pthread_atfork(3) funtions, as there are performed
internal allocations that are not freed for the time of running StopTheWorld()
code. This avoids false-positives.
The same changes have to be replicated in the ASan and LSan runtime.
Non-NetBSD OSs are not tested and this code is restricted to NetBSD only.
Reviewers: dvyukov, joerg, mgorny, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67331
llvm-svn: 372459
Summary:
Do not grab the allocator lock before calling dl_iterate_phdr. This may
cause a lock order inversion with (valid) user code that uses malloc
inside a dl_iterate_phdr callback.
Reviewers: vitalybuka, hctim
Subscribers: jfb, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67738
llvm-svn: 372348
After r372209, the compile command can end up including an argument with
quotes in it, e.g.
-fprofile-instr-use="/foo/bar.profdata"
when invoking the compiler with execute_process, the compiler ends up
getting that argument with quotes and all, and fails to open the file.
This all seems horribly broken, but one way of working around it is to
simply strip the quotes from the string here. If they were there to
protect a path that's got spaces in it, that wasn't going to work
anyway because the string is later split by spaces.
llvm-svn: 372312
Fuchsia doesn't have /proc/id/maps, so it relies on the kernel logging system
to provide the DSO map to be able to symbolize in the context of ASLR. The DSO
map is logged automatically on Fuchsia when encountering a crash or writing to
the sanitizer log for the first time in a process. There are several cases
where libFuzzer doesn't encounter a crash, e.g. on timeouts, OOMs, and when
configured to print new PCs as they become covered, to name a few. Therefore,
this change always writes to the sanitizer log on startup to ensure the DSO map
is available in the log.
Author: aarongreen
Differential Revision: https://reviews.llvm.org/D66233
llvm-svn: 372056
This fixes a test failure in instrprof-set-file-object-merging.c which
seems to have been caused by reuse of stale data in old raw profiles.
llvm-svn: 372041
Summary:
.init_array gets optimized away when building with -O2 and as a result,
check_cxx_section_exists failed to pass -DCOMPILER_RT_HAS_INITFINI_ARRAY
when building crtbegin.o and crtend.o, which causes binaries linked with
them encounter segmentation fault. See https://crbug.com/855759 for
details. This change prevents .init_array section to be optimized away
even with -O2 or higher optimization level.
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67628
llvm-svn: 372038
Summary:
If the cache variable named in `${valid_archs}` (e.g. `DARWIN_osx_BUILTIN_ARCHS`)
is set in the cache but is empty then the cache check
`if(${valid_archs})` will be false so the function will probe the
compiler but the `set(...)` command at the end of the function to update
the cache variable will be a no-op. This is because `set(...)` will not
update an existing cache variable unless the `FORCE` argument is
provided.
To fix this this patch adds `FORCE` so the cache is always updated.
rdar://problem/55323665
Reviewers: vsk, kubamracek
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67530
llvm-svn: 371872
built-ins from the rest of compiler-rt.
The detection of supported platform (os) architectures for Darwin relies
on the `darwin_test_archs()` CMake function. This is used both for
building the builtins (`builtin-config-ix.cmake`) and for the rest of
the compiler-rt (`config-ix.cmake`).
`darwin_test_archs()` implements a cache, presumably to speed up CMake
re-configures. Unfortunately this caching is buggy because it depends
on external global state (i.e. the `TEST_COMPILE_ONLY` variable) and
this is not taken into account. For `config-ix.cmake`
`TEST_COMPILE_ONLY` is not set and for `builtin-config-ix.cmake`
`TEST_COMPILE_ONLY` is set to `On`. This makes the
`darwin_test_archs()` function racey in the sense that a call from one
calling context will poison the cache for the other calling context.
This is actually an issue George Karpenkov discovered a while back
and had an incomplete patch for (https://reviews.llvm.org/D45337)
but this was never merged.
To workaround this, this patch switches to using a different set of
variables for the platform architecture builtins, i.e.
`DARWIN_<OS>_ARCHS` -> `DARWIN_<OS>_BUILTIN_ARCHS`. This avoids the
cache poisoning problem because the cached variable names are different.
This also has the advantage that the the configured architectures for
builtins and the rest of the compiler-rt are now independent and
can be set differently if necessary.
Note in `darwin_test_archs()` we also now pass `-w` to the compiler
because `try_compile_only()` treats compiler warnings as errors. This
was extremely fragile because compiler warnings (can easily appear due
to a buggy compiler or SDK headers) would cause compiler-rt to think an
architecture on Darwin wasn't supported.
rdar://problem/48637491
llvm-svn: 371871
Summary:
getauxval() is not available on NetBSD and there is no a direct equivalent.
Add a function that implements the same semantics with NetBSD internals.
Reorder the GetPageSize() functions to prefer the sysctl approach for NetBSD.
It no longer makes a difference which approach is better. Avoid changing
conditional code path.
Reviewers: vitalybuka, dvyukov, mgorny, joerg
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67329
llvm-svn: 371758
Summary:
many_tls_keys_pthread.cpp for TSD
many_tls_keys_thread.cpp for TLS
The TSD test is unsupported on NetBSD as it assumes TLS used internally.
TSD on NetBSD does not use TLS.
Reviewers: joerg, vitalybuka, mgorny, dvyukov, kcc
Reviewed By: vitalybuka
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67428
llvm-svn: 371757
When cross-compiling compiler-rt as part of LLVM e. g. for Linux on
a Windows host and using the just-built clang as cross-compiler, we set
the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level
cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty
string in the nested cmake invocation for building builtins.
But the compiler for compiling test cases is meant to be run on host,
therefore it may have the '.exe' suffix.
Handle this by asking cmake about the host system.
Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com>
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D67401
llvm-svn: 371754
Summary:
This changes a few things to improve memory footprint and performances
on Android, and fixes a test compilation error:
- add `stdlib.h` to `wrappers_c_test.cc` to address
https://bugs.llvm.org/show_bug.cgi?id=42810
- change Android size class maps, based on benchmarks, to improve
performances and lower the Svelte memory footprint. Also change the
32-bit region size for said configuration
- change the `reallocate` logic to reallocate in place for sizes larger
than the original chunk size, when they still fit in the same block.
This addresses patterns from `memory_replay` dumps like the following:
```
202: realloc 0xb48fd000 0xb4930650 12352
202: realloc 0xb48fd000 0xb48fd000 12420
202: realloc 0xb48fd000 0xb48fd000 12492
202: realloc 0xb48fd000 0xb48fd000 12564
202: realloc 0xb48fd000 0xb48fd000 12636
202: realloc 0xb48fd000 0xb48fd000 12708
202: realloc 0xb48fd000 0xb48fd000 12780
202: realloc 0xb48fd000 0xb48fd000 12852
202: realloc 0xb48fd000 0xb48fd000 12924
202: realloc 0xb48fd000 0xb48fd000 12996
202: realloc 0xb48fd000 0xb48fd000 13068
202: realloc 0xb48fd000 0xb48fd000 13140
202: realloc 0xb48fd000 0xb48fd000 13212
202: realloc 0xb48fd000 0xb48fd000 13284
202: realloc 0xb48fd000 0xb48fd000 13356
202: realloc 0xb48fd000 0xb48fd000 13428
202: realloc 0xb48fd000 0xb48fd000 13500
202: realloc 0xb48fd000 0xb48fd000 13572
202: realloc 0xb48fd000 0xb48fd000 13644
202: realloc 0xb48fd000 0xb48fd000 13716
202: realloc 0xb48fd000 0xb48fd000 13788
...
```
In this situation we were deallocating the old chunk, and
allocating a new one for every single one of those, but now we can
keep the same chunk (we just updated the header), which saves some
heap operations.
Reviewers: hctim, morehouse, vitalybuka, eugenis, cferris, rengolin
Reviewed By: morehouse
Subscribers: srhines, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67293
llvm-svn: 371628
Dan Liew