This patch replaces three different pre-existing implementations of
__div[sdt]f3 LibCalls with a generic one - like it is already done for
many other LibCalls.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85031
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
It's not undefined behavior for an unsigned left shift to overflow (i.e. to
shift bits out), but it has been the source of bugs and exploits in certain
codebases in the past. As we do in other parts of UBSan, this patch adds a
dynamic checker which acts beyond UBSan and checks other sources of errors. The
option is enabled as part of -fsanitize=integer.
The flag is named: -fsanitize=unsigned-shift-base
This matches shift-base and shift-exponent flags.
<rdar://problem/46129047>
Differential Revision: https://reviews.llvm.org/D86000
Add functions exposed via the MSAN interface to enable MSAN within
binaries that perform manual stack switching (e.g. through using fibers
or coroutines).
This functionality is analogous to the fiber APIs available for ASAN and TSAN.
Fixesgoogle/sanitizers#1232
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86471
The introduction of find_library for ncurses caused more issues than it solved problems. The current open issue is it makes the static build of LLVM fail. It is better to revert for now, and get back to it later.
Revert "[CMake] Fix an issue where get_system_libname creates an empty regex capture on windows"
This reverts commit 1ed1e16ab8.
Revert "Fix msan build"
This reverts commit 34fe9613dd.
Revert "[CMake] Always mark terminfo as unavailable on Windows"
This reverts commit 76bf26236f.
Revert "[CMake] Fix OCaml build failure because of absolute path in system libs"
This reverts commit 8e4acb82f7.
Revert "[CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF"
This reverts commit 495f91fd33.
Revert "Use find_library for ncurses"
This reverts commit a52173a3e5.
Differential revision: https://reviews.llvm.org/D86521
The CrossOver mutator is meant to cross over two given buffers (referred to as
the first/second buffer henceforth). Previously InsertPartOf/CopyPartOf calls
used in the CrossOver mutator incorrectly inserted/copied part of the second
buffer into a "scratch buffer" (MutateInPlaceHere of the size
CurrentMaxMutationLen), rather than the first buffer. This is not intended
behavior, because the scratch buffer does not always (i) contain the content of
the first buffer, and (ii) have the same size as the first buffer;
CurrentMaxMutationLen is typically a lot larger than the size of the first
buffer. This patch fixes the issue by using the first buffer instead of the
scratch buffer in InsertPartOf/CopyPartOf calls.
A FuzzBench experiment was run to make sure that this change does not
inadvertently degrade the performance. The performance is largely the same; more
details can be found at:
https://storage.googleapis.com/fuzzer-test-suite-public/fixcrossover-report/index.html
This patch also adds two new tests, namely "cross_over_insert" and
"cross_over_copy", which specifically target InsertPartOf and CopyPartOf,
respectively.
- cross_over_insert.test checks if the fuzzer can use InsertPartOf to trigger
the crash.
- cross_over_copy.test checks if the fuzzer can use CopyPartOf to trigger the
crash.
These newly added tests were designed to pass with the current patch, but not
without the it (with 790878f291 these tests do not
pass). To achieve this, -max_len was intentionally given a high value. Without
this patch, InsertPartOf/CopyPartOf will generate larger inputs, possibly with
unpredictable data in it, thereby failing to trigger the crash.
The test pass condition for these new tests is narrowed down by (i) limiting
mutation depth to 1 (i.e., a single CrossOver mutation should be able to trigger
the crash) and (ii) checking whether the mutation sequence of "CrossOver-" leads
to the crash.
Also note that these newly added tests and an existing test (cross_over.test)
all use "-reduce_inputs=0" flags to prevent reducing inputs; it's easier to
force the fuzzer to keep original input string this way than tweaking
cov-instrumented basic blocks in the source code of the fuzzer executable.
Differential Revision: https://reviews.llvm.org/D85554
value-profile-load.test needs adjustment with a mutator change in
bb54bcf849, which reverted as of now, but will be
recommitted after landing this patch.
This patch makes value-profile-load.test more friendly to (and aware of) the
current value profiling strategy, which is based on the hamming as well as the
absolute distance. To this end, this patch adjusts the set of input values that
trigger an expected crash. More specifically, this patch now uses a single value
0x01effffe as a crashing input, because this value is close to values like
{0x1ffffff, 0xffffff, ...}, which are very likely to be added to the corpus per
the current hamming- and absolute-distance-based value profiling strategy. Note
that previously the crashing input values were {1234567 * {1, 2, ...}, s.t. <
INT_MAX}.
Every byte in the chosen value 0x01effeef is intentionally different; this was
to make it harder to find the value without the intermediate inputs added to the
corpus by the value profiling strategy.
Also note that LoadTest.cpp now uses a narrower condition (Size != 8) for
initial pruning of inputs, effectively preventing libFuzzer from generating
inputs longer than necessary and spending time on mutating such long inputs in
the corpus - a functionality not meant to be tested by this specific test.
Differential Revision: https://reviews.llvm.org/D86247
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Simply don't mark the file as C and CMake will recognize the rest.
This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple.
Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09.
Afterwards workarounds were added for MinGW and Apple:
* https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
* https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb
The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other.
The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287).
Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Example error:
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D86308
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulo_impl.inc for better maintainability.
This patch is almost identical to D86277.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86289
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulv_impl.inc for better maintainability.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86277
Fixes a build failure in the Darwin kernel. Tested with:
% nm -mU lib/libclang_rt.cc_kext_x86_64h_osx.a | grep __llvm_profile_raw_version
rdar://67809173
Currently, libFuzzer will exit with an error message if a non-existent
corpus directory is provided. However, if a user provides a non-existent
directory for the `artifact_prefix`, `exact_artifact_path`, or
`features_dir`, libFuzzer will continue execution but silently fail to
write artifacts/features.
To improve the user experience, this PR adds validation for the existence of
all user supplied directories before executing the main fuzzing loop. If they
don't exist, libFuzzer will exit with an error message.
Patch By: dgg5503
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D84808
With the 'new' way of releasing on 32-bit, we iterate through all the
regions in between `First` and `Last`, which covers regions that do not
belong to the class size we are working with. This is effectively wasted
cycles.
With this change, we add a `SkipRegion` lambda to `releaseFreeMemoryToOS`
that will allow the release function to know when to skip a region.
For the 64-bit primary, since we are only working with 1 region, we never
skip.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D86399
* Make the three tests look more uniformly
* Explicitly specify types of integer and floating point literals
* Add more test cases (mostly inspired by divtf3_test.c)
- tests are added for obviously special cases such as +/-Inf, +/-0.0 and some
more implementation-specific cases such as divisor being almost 1.0
* Make NaN in the second test case of `divtf3` to be `sNaN` instead of
testing for `qNaN` again
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D84932
FreeBSD doesn't provide a crypt.h header but instead defines the functions
in unistd.h. Use __has_include() to handle that case.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D85406
FreeBSD delivers a SIGBUS signal for bad addresses rather than SIGSEGV.
Reviewed By: #sanitizers, vitalybuka, yln
Differential Revision: https://reviews.llvm.org/D85409
The dynamically linked ASan tests rely on `LD_LIBRARY_PATH` to find
`libclang_rt.asan-*.so` at runtime.
However, the Solaris runtime linker `ld.so.1` also supports more specific
variables: `LD_LIBRARY_PATH_32` and `LD_LIBRARY_PATH_64` respectively. If
those happen to be set, `LD_LIBRARY_PATH` is ignored. In such a case, all
dynamically linked ASan tests `FAIL`. For i386 alone, this affects about
200 tests.
The following patch fixes that by also setting `LD_LIBRARY_PATH_{32,64}` on
Solaris.
Tested on `amd64-pc-solaris2.11` both with only `LD_LIBRARY_PATH` set and
with `LD_LIBRARY_PATH_{32,64}` set too.
Differential Revision: https://reviews.llvm.org/D86333
Support -march=sapphirerapids for x86.
Compare with Icelake Server, it includes 14 more new features. They are
amxtile, amxint8, amxbf16, avx512bf16, avx512vp2intersect, cldemote,
enqcmd, movdir64b, movdiri, ptwrite, serialize, shstk, tsxldtrk, waitpkg.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D86503
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86367
libtool already produces a table of contents, and ranlib just gives
spurious errors because it doesn't understand universal binaries.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86365
Handle NULL address argument in the `mach_vm_[de]allocate()`
interceptors and fix test: `Assignment 2` is not valid if we weren't
able to re-allocate memory.
rdar://67680613
Currently SimpleCmpTest passes after 9,831,994 trials on x86_64/Linux
when the number of given trials is 10,000,000, just a little bigger than
that. This patch modifies SimpleCmpTest.cpp so that the test passes with less
trials, reducing its chances of future failures as libFuzzer evolves. More
specifically, this patch changes a 32-bit equality check to a 8-bit equality
check, making this test pass at 4,635,303 trials.
Differential Revision: https://reviews.llvm.org/D86382
D80465 added an assembly implementation of muldi3 for RISC-V but it didn't
add it to the cmake `*_SOURCES` list, so the C implementation was being used
instead. This patch fixes that.
Differential Revision: https://reviews.llvm.org/D86036
Instead of ANDing with a one hot mask representing the bit to
be tested, we were ANDing with just the bit number. This tests
multiple bits none of them the correct one.
This caused skylake-avx512, cascadelake and cooperlake to all
be misdetected. Based on experiments with the Intel SDE, it seems
that all of these CPUs are being detected as being cooperlake.
This is bad since its the newest CPU of the 3.
We are now using a properly-substituted minimal deployment target
compiler flag (`%min_macos_deployment_target=10.11`). Enable test on
iOS and watchOS plus simulators. We are also not testing on very old
platforms anymore, so we can remove some obsolete lit infrastructure.
* Support macOS 11+ version scheme
* Standardize substitution name `%min_deployment_target=x.y`
* Remove unneeded error cases (the input version is hard-coded)
* Specify version as tuple instead of string; no need to parse it
These changes should also facilitate a future addition of a substitution
that expands to "set deployment target to current target version"
(https://reviews.llvm.org/D70151).
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D85925
We don't test on very old versions of Apple platforms anymore. The
following lit substitution concerning the minimum deployment target for
ARC support can be removed.
```
%darwin_min_target_with_full_runtime_arc_support -> 10.11
```
Differential Revision: https://reviews.llvm.org/D85803
After removing the unnecessary `-mmacosx-version-min=10.12` compiler
flag this test can run on all platforms. I confirmed that this test is
green for iOS, iOS simulator, and watchOS simulator.
Differential Revision: https://reviews.llvm.org/D85952
This reverts commit d58fd4e521. This broke
compiler-rt compilation on macOS:
codesign --sign - /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/clang/12.0.99/lib/darwin/libclang_rt.tsan_ios_dynamic.dylib
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_amd64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_aarch64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
Undefined symbols for architecture arm64:
"_wrap__setjmp", referenced from:
substitution__setjmp in tsan_interceptors_posix.cpp.o
"_wrap_setjmp", referenced from:
substitution_setjmp in tsan_interceptors_posix.cpp.o
"_wrap_sigsetjmp", referenced from:
substitution_sigsetjmp in tsan_interceptors_posix.cpp.o
ld: symbol(s) not found for architecture arm64
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Instead enable the ASM language and mark the files as being ASM.
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Patch By: tambre
Differential Revision: https://reviews.llvm.org/D85706
The behavior of the CrossOver mutator has changed with
bb54bcf849. This seems to affect the
value-profile-load test on Darwin. This patch provides a wider margin for
determining success of the value-profile-load test, by testing the targeted
functionality (i.e., GEP index value profile) more directly and faster. To this
end, LoadTest.cpp now uses a narrower condition (Size != 8) for initial pruning
of inputs, effectively preventing libFuzzer from generating inputs longer than
necessary and spending time on mutating such long inputs in the corpus - a
functionality not meant to be tested by this specific test.
Previously, on x86/Linux, it required 6,597,751 execs with -use_value_profile=1
and 19,605,575 execs with -use_value_profile=0 to hit the crash. With this
patch, the test passes with 174,493 execs, providing a wider margin from the
given trials of 10,000,000. Note that, without the value profile (i.e.,
-use_value_profile=0), the test wouldn't pass as it still requires 19,605,575
execs to hit the crash.
Differential Revision: https://reviews.llvm.org/D86247
InitializeInterceptors() calls dlsym(), which calls calloc(). Depending
on the allocator implementation, calloc() may invoke mmap(), which
results in a segfault since REAL(mmap) is still being resolved.
We fix this by doing a direct syscall if interceptors haven't been fully
resolved yet.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86168
D85820 introduced a bug where LLVM_ENABLE_TERMINFO was set to true when
the library was found, even when the user had set
-DLLVM_ENABLE_TERMINFO=OFF.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D86173
`dispatch_async_and_wait()` was introduced in macOS 10.14. Let's
forward declare it to ensure we can compile the test with older SDKs and
guard execution by checking if the symbol is available. (We can't use
`__builtin_available()`, because that itself requires a higher minimum
deployment target.) We also need to specify the `-undefined
dynamic_lookup` compiler flag.
Differential Revision: https://reviews.llvm.org/D85995
`dispatch_async_and_wait()` was introduced in macOS 10.14, which is
greater than our minimal deployment target. We need to forward declare
it as a "weak import" to ensure we generate a weak reference so the TSan
dylib continues to work on older systems. We cannot simply `#include
<dispatch.h>` or use the Darwin availability macros since this file is
multi-platform.
In addition, we want to prevent building these interceptors at all when
building with older SDKs because linking always fails.
Before:
```
➤ dyldinfo -bind ./lib/clang/12.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib | grep dispatch_async_and_wait
__DATA __interpose 0x000F5E68 pointer 0 libSystem _dispatch_async_and_wait_f
```
After:
```
➤ dyldinfo -bind ./lib/clang/12.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib | grep dispatch_async_and_wait
__DATA __got 0x000EC0A8 pointer 0 libSystem _dispatch_async_and_wait (weak import)
__DATA __interpose 0x000F5E78 pointer 0 libSystem _dispatch_async_and_wait (weak import)
```
This is a follow-up to D85854 and should fix:
https://reviews.llvm.org/D85854#2221529
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D86103
The linker errors caused by this revision have been addressed.
Add interceptors for `dispatch_async_and_wait[_f]()` which was added in
macOS 10.14. This pair of functions is similar to `dispatch_sync()`,
but does not force a context switch of the queue onto the caller thread
when the queue is active (and hence is more efficient). For TSan, we
can apply the same semantics as for `dispatch_sync()`.
From the header docs:
> Differences with dispatch_sync()
>
> When the runtime has brought up a thread to invoke the asynchronous
> workitems already submitted to the specified queue, that servicing
> thread will also be used to execute synchronous work submitted to the
> queue with dispatch_async_and_wait().
>
> However, if the runtime has not brought up a thread to service the
> specified queue (because it has no workitems enqueued, or only
> synchronous workitems), then dispatch_async_and_wait() will invoke the
> workitem on the calling thread, similar to the behaviour of functions
> in the dispatch_sync family.
Additional context:
> The guidance is to use `dispatch_async_and_wait()` instead of
> `dispatch_sync()` when it is necessary to mix async and sync calls on
> the same queue. `dispatch_async_and_wait()` does not guarantee
> execution on the caller thread which allows to reduce context switches
> when the target queue is active.
> https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057
rdar://35757961
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D85854
The CrossOver mutator is meant to cross over two given buffers (referred to as
the first/second buffer henceforth). Previously InsertPartOf/CopyPartOf calls
used in the CrossOver mutator incorrectly inserted/copied part of the second
buffer into a "scratch buffer" (MutateInPlaceHere of the size
CurrentMaxMutationLen), rather than the first buffer. This is not intended
behavior, because the scratch buffer does not always (i) contain the content of
the first buffer, and (ii) have the same size as the first buffer;
CurrentMaxMutationLen is typically a lot larger than the size of the first
buffer. This patch fixes the issue by using the first buffer instead of the
scratch buffer in InsertPartOf/CopyPartOf calls.
A FuzzBench experiment was run to make sure that this change does not
inadvertently degrade the performance. The performance is largely the same; more
details can be found at:
https://storage.googleapis.com/fuzzer-test-suite-public/fixcrossover-report/index.html
This patch also adds two new tests, namely "cross_over_insert" and
"cross_over_copy", which specifically target InsertPartOf and CopyPartOf,
respectively.
- cross_over_insert.test checks if the fuzzer can use InsertPartOf to trigger
the crash.
- cross_over_copy.test checks if the fuzzer can use CopyPartOf to trigger the
crash.
These newly added tests were designed to pass with the current patch, but not
without the it (with 790878f291 these tests do not
pass). To achieve this, -max_len was intentionally given a high value. Without
this patch, InsertPartOf/CopyPartOf will generate larger inputs, possibly with
unpredictable data in it, thereby failing to trigger the crash.
The test pass condition for these new tests is narrowed down by (i) limiting
mutation depth to 1 (i.e., a single CrossOver mutation should be able to trigger
the crash) and (ii) checking whether the mutation sequence of "CrossOver-" leads
to the crash.
Also note that these newly added tests and an existing test (cross_over.test)
all use "-reduce_inputs=0" flags to prevent reducing inputs; it's easier to
force the fuzzer to keep original input string this way than tweaking
cov-instrumented basic blocks in the source code of the fuzzer executable.
Differential Revision: https://reviews.llvm.org/D85554
Two tests `FAIL` on 32-bit sparc:
Profile-sparc :: Posix/instrprof-gcov-parallel.test
UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp
The failure mode is similar:
Undefined first referenced
symbol in file
__atomic_store_4 /var/tmp/instrprof-gcov-parallel-6afe8d.o
__atomic_load_4 /var/tmp/instrprof-gcov-parallel-6afe8d.o
Undefined first referenced
symbol in file
__atomic_load_1 /var/tmp/cast-overflow-72a808.o
This is a known bug: `clang` doesn't inline atomics on 32-bit sparc, unlike
`gcc`.
The patch therefore `XFAIL`s the tests.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85346
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Differential revision: https://reviews.llvm.org/D85820
While the instrumentation never calls dfsan_union in fast16labels mode,
the custom wrappers do. We detect fast16labels mode by checking whether
any labels have been created. If not, we must be using fast16labels
mode.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86012
This sets some config parameters so we can run the asan tests with
llvm-lit,
e.g. `./bin/llvm-lit [...]/compiler-rt/test/asan`
Differential Revision: https://reviews.llvm.org/D83821
Otherwise, lots of these tests fail with a CHECK error similar to:
==12345==AddressSanitizer CHECK failed: compiler-rt/lib/asan/asan_posix.cpp:120 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
This is because the default pthread stubs in FreeBSD's libc always
return failures (such as ENOSYS for pthread_key_create) in case the
pthread library is not linked in.
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D85082
Have the front-end use the `nounwind` attribute on atomic libcalls.
This prevents us from seeing `invoke __atomic_load` in MSAN, which
is problematic as it has no successor for instrumentation to be added.
Unmapping and remapping is dangerous since another thread could touch
the shadow memory while it is unmapped. But there is really no need to
unmap anyway, since mmap(MAP_FIXED) will happily clobber the existing
mapping with zeroes. This is thread-safe since the mmap() is done under
the same kernel lock as page faults are done.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D85947
Add interceptors for `dispatch_async_and_wait[_f]()` which was added in
macOS 10.14. This pair of functions is similar to `dispatch_sync()`,
but does not force a context switch of the queue onto the caller thread
when the queue is active (and hence is more efficient). For TSan, we
can apply the same semantics as for `dispatch_sync()`.
From the header docs:
> Differences with dispatch_sync()
>
> When the runtime has brought up a thread to invoke the asynchronous
> workitems already submitted to the specified queue, that servicing
> thread will also be used to execute synchronous work submitted to the
> queue with dispatch_async_and_wait().
>
> However, if the runtime has not brought up a thread to service the
> specified queue (because it has no workitems enqueued, or only
> synchronous workitems), then dispatch_async_and_wait() will invoke the
> workitem on the calling thread, similar to the behaviour of functions
> in the dispatch_sync family.
Additional context:
> The guidance is to use `dispatch_async_and_wait()` instead of
> `dispatch_sync()` when it is necessary to mix async and sync calls on
> the same queue. `dispatch_async_and_wait()` does not guarantee
> execution on the caller thread which allows to reduce context switches
> when the target queue is active.
> https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057
rdar://35757961
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D85854
base and nptr_label were swapped, which meant we were passing nptr's
shadow as the base to the operation. Usually, the shadow is 0, which
causes strtoull to guess the correct base from the string prefix (e.g.,
0x means base-16 and 0 means base-8), hiding this bug. Adjust the test
case to expose the bug.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D85935
A recent change to sanitizer_common caused us to issue the syscall
madvise(MADV_HUGEPAGE) during HWASAN initialization. This may lead to a
problem if madvise is instrumented (e.g. because libc is instrumented
or the user intercepted it). For example, on Android the syscall may
fail if the kernel does not support transparent hugepages, which leads
to an attempt to set errno in a HWASAN instrumented function. Avoid
this problem by introducing a syscall wrapper and using it to issue
this syscall.
Tested only on Linux; includes untested updates for the other
platforms.
Differential Revision: https://reviews.llvm.org/D85870
Disable huge pages in the TSan shadow regions when no_huge_pages_for_shadow == true (default).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D85841
Similarly as for pointers, even for integers a == b is usually false.
GCC also uses this heuristic.
Reviewed By: ebrevnov
Differential Revision: https://reviews.llvm.org/D85781
When building on `sparc64-unknown-linux-gnu`, I found that a large number
of `SanitizerCommon-asan-sparc*-Linux` tests were `FAIL`ing, like
SanitizerCommon-asan-sparc-Linux :: Linux/aligned_alloc-alignment.cpp
[...]
SanitizerCommon-asan-sparcv9-Linux :: Linux/aligned_alloc-alignment.cpp
[...]
many of them due to
fatal error: error in backend: Function "_Z14User_OnSIGSEGViP9siginfo_tPv": over-aligned dynamic alloca not supported.
which breaks ASan on Sparc. Currently ASan is only built for the benefit
of `gcc` where it does work. However, when enabling the compilation in
`compiler-rt` to make certain it continues to build, I missed
`compiler-rt/test/sanitizer_common` when disabling ASan testing on Sparc
(it's not yet enabled on Solaris).
This patch fixes the issue.
Tested on `sparcv9-sun-solaris2.11` with the `sanitizer_comon` testsuite enabled.
Differential Revision: https://reviews.llvm.org/D85732
Every now and then SystemZ programs built with ASan crash with
ERROR: AddressSanitizer: stack-overflow on address 0x040000000000
for no apparent reason. The problem is that
BufferedStackTrace::UnwindFast() is specialized for SystemZ: it takes
register 14 from the frame, however, IsValidFrame() is not
specialized, and does not guarantee that frame[14] is going to be a
valid memory access.
Fix by introducing per-arch kFrameSize and using it in IsValidFrame().
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D85822
This fixes https://bugs.llvm.org/show_bug.cgi?id=47118. Before this change, when the sigaction interceptor prevented a signal from being changed, it also prevented the oldact output parameter from being written to. This resulted in a use-of-uninitialized-variable by any program that used sigaction for the purpose of reading signals.
This change fixes this: the regular sigaction implementation is still called, but with the act parameter nullified, preventing any changes.
Patch By: IanPudney
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85797
Commit 9385aaa848 ("[sancov] Fix PR33732") added zeroext to
__sanitizer_cov_trace(_const)?_cmp[1248] parameters for x86_64 only,
however, it is useful on other targets, in particular, on SystemZ: it
fixes swap-cmp.test.
Therefore, use it on all targets. This is safe: if target ABI does not
require zero extension for a particular parameter, zeroext is simply
ignored. A similar change has been implemeted as part of commit
3bc439bdff ("[MSan] Add instrumentation for SystemZ"), and there were
no problems with it.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85689
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
When one tries to minimize timeouts using -minimize_crash=1,
minimization immediately fails. The following sequence of events is
responsible for this:
[parent] SIGALRM occurs
[parent] read() returns -EINTR (or -ERESTARTSYS according to strace)
[parent] fgets() returns NULL
[parent] ExecuteCommand() closes child's stdout and returns
[child ] SIGALRM occurs
[child ] AlarmCallback() attempts to write "ALARM: ..." to stdout
[child ] Dies with SIGPIPE without calling DumpCurrentUnit()
[parent] Does not see -exact_artifact_path and exits
When minimizing, the timer in parent is not necessary, so fix by not
setting it in this case.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85359
On iOS, when we `longjmp()` out of the signal handler, a subsequent call
to `sigaltstack()` still reports that we are executing on the signal
handler stack.
Tracking rdar://66789814
Differential Revision: https://reviews.llvm.org/D85677
Two tests currently `XPASS` on sparcv9:
Unexpectedly Passed Tests (2):
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
The following patch fixes this.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85119
Two ubsan tests FAIL on Sparc:
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
I've reported the details in Bug 47015, but it boils down to the fact that
the `s1` subtest actually incurs a fault on strict-alignment targets like
Sparc which UBSan doesn't expect.
This can be fixed like the `w1` subtest by compiling with
`-fno-sanitize-recover=alignment`.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D85433
The former function is particularly optimized for exactly the
use case we're interested in: an all-zero buffer.
This reduces the overhead of calling this function some 80% or
more. This is particularly for instrumenting code heavy with
string processing functions, like grep. An invocation of grep
with the pattern '[aeiou]k[aeiou]' has its runtime reduced by
~75% with this patch
Differential Revision: https://reviews.llvm.org/D84961
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
As pointed out in D85387, part of the comment for MapDynamicShadow
refactored to sanitizer_common in D83247 was incorrect for non-Linux
versions. Update the comment to reflect that.
Running ninja check-sanitizer fails for after that patch (commit
058f5f6fd8) with the following error:
libRTSanitizerCommon.test.nolibc.x86_64.a(sanitizer_posix.cpp.o): In
function `__sanitizer::GetNamedMappingFd(char const*, unsigned long,
int*)':
..../llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix.cpp:358:
undefined reference to `fcntl'
clang-12: error: linker command failed with exit code 1 (use -v to see
invocation)
This patch works around the problem by only calling fcntl if O_CLOEXEC
is not defined.
Reviewed By: plopresti
Differential Revision: https://reviews.llvm.org/D85114
When the FreeBSD qsort() implementation recurses, it does so using an
interposable function call, so we end up calling the interceptor again
and set the saved comparator to wrapped_qsort_compar. This results in an
infinite loop and a eventually a stack overflow since wrapped_qsort_compar
ends up calling itself. This means that ASAN is completely broken on
FreeBSD for programs that call qsort(). I found this while running
check-all on a FreeBSD system a ASAN-instrumented LLVM.
Fix this by checking whether we are recursing inside qsort before writing
to qsort_compar. The same bug exists in the qsort_r interceptor, so use the
same approach there. I did not test the latter since the qsort_r function
signature does not match and therefore it's not intercepted on FreeBSD/macOS.
Fixes https://llvm.org/PR46832
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D84509
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This change adds a CMake rule to produce shared object versions of
libFuzzer (no-main). Like the static library versions, these shared
libraries have a copy of libc++ statically linked in. For i386 we don't
link with libc++ since i386 does not support mixing position-
independent and non-position-independent code in the same library.
Patch By: IanPudney
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D84947
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
* Add SystemZ to the list of supported architectures.
* XFAIL a few tests.
Coverage reporting is broken, and is not easy to fix (see comment in
coverage.test). Interaction with sanitizers needs to be investigated
more thoroughly, since they appear to reduce coverage in certain cases.
Anatoly Trosinenko