Commit Graph

13013 Commits

Author SHA1 Message Date
Azharuddin Mohammed 7ed3286a51 [LibFuzzer] [tests] [Darwin] Use the pthread library from the SDK 2020-08-21 09:22:13 -07:00
Luís Marques 57903cf093 [compiler-rt][RISCV] Use muldi3 builtin assembly implementation
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
2020-08-21 13:06:35 +01:00
Craig Topper df9a9bb7be [X86] Correct the implementation of the testFeature macro in getIntelProcessorTypeAndSubtype to do a proper bit test.
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.
2020-08-20 23:50:45 -07:00
Vitaly Buka 66c882e529 Revert "[libFuzzer] Fix value-profile-load test."
D86247 fails on Windows.

This reverts commit 428bebaf10.
2020-08-20 17:49:12 -07:00
Vitaly Buka ea9bf460a8 [NFC][libFuzzer] Try to fix test on Windows
Broken after D86247
2020-08-20 17:33:51 -07:00
Julian Lettner 53aff8d864 [Darwin][iOS] Enable test on non-macOS platforms
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.
2020-08-20 16:40:32 -07:00
Julian Lettner 1f3c92f968 [compiler-rt][Darwin] Refactor minimum deployment target substitutions
* 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
2020-08-20 16:22:56 -07:00
Julian Lettner d9b062ad87 [TSan][Darwin] Remove unnecessary lit substitution
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
2020-08-20 13:00:32 -07:00
Julian Lettner 6222a28db5 [TSan][Darwin] Enable test on non-macOS platforms
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
2020-08-20 12:28:05 -07:00
Raphael Isemann adf0b8cc70 Revert "[compiler-rt] Compile assembly files as ASM not C"
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
2020-08-20 15:25:22 +02:00
Petr Hosek d58fd4e521 [compiler-rt] Compile assembly files as ASM not C
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
2020-08-20 00:34:59 -07:00
Dokyung Song 428bebaf10 [libFuzzer] Fix value-profile-load test.
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
2020-08-19 22:14:43 +00:00
Matt Morehouse 4deda57106 [DFSan] Handle mmap() calls before interceptors are installed.
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
2020-08-19 15:07:41 -07:00
Peter Collingbourne a208ad5ddb sanitizer_common: Use void* for madvise first argument on Solaris.
Differential Revision: https://reviews.llvm.org/D86166
2020-08-19 10:55:55 -07:00
Petr Hosek 495f91fd33 [CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF
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
2020-08-19 10:31:42 -07:00
Julian Lettner 40ae296bc3 [TSan][libdispatch] Guard test execution on old platforms
`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
2020-08-18 18:34:14 -07:00
Julian Lettner 686fe293e6 [TSan][libdispatch] Ensure TSan dylib works on old systems
`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
2020-08-18 18:34:14 -07:00
Julian Lettner 0c4863a253 Reland "[TSan][libdispatch] Add interceptors for dispatch_async_and_wait()"
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
2020-08-18 18:34:14 -07:00
Arthur Eubanks 501a078cbb Revert "[TSan][libdispatch] Add interceptors for dispatch_async_and_wait()"
This reverts commit d137db8029.

Breaks builds on older SDKs.
2020-08-18 09:49:05 -07:00
Dokyung Song bb54bcf849 [libFuzzer] Fix arguments of InsertPartOf/CopyPartOf calls in CrossOver mutator.
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
2020-08-18 16:09:18 +00:00
Rainer Orth 13080ca1f0 [compiler-rt][test] XFAIL two tests on 32-bit sparc
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
2020-08-18 11:32:51 +02:00
Harmen Stoppels a52173a3e5 Use find_library for ncurses
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
2020-08-17 19:52:52 -07:00
Dávid Bolvanský 0f14b2e6cb Revert "[BPI] Improve static heuristics for integer comparisons"
This reverts commit 50c743fa71. Patch will be split to smaller ones.
2020-08-17 20:44:33 +02:00
Matt Morehouse 69721fc9d1 [DFSan] Support fast16labels mode in dfsan_union.
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
2020-08-17 11:27:28 -07:00
Amy Huang 51c152ca2a Revert "Make compiler-rt/asan tests run with llvm-lit."
This reverts commit 7f84f62ef0.

Seems to be causing a bunch of compiler-rt test failures on
ppc64-linux bots.
2020-08-17 10:00:45 -07:00
Amy Huang 7f84f62ef0 Make compiler-rt/asan tests run with llvm-lit.
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
2020-08-17 09:24:19 -07:00
Dimitry Andric 3aecf4bdf3 On FreeBSD, add -pthread to ASan dynamic compile flags for tests
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
2020-08-15 13:05:31 +02:00
Gui Andrade 97de0188dd [MSAN] Reintroduce libatomic load/store instrumentation
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.
2020-08-14 20:31:10 +00:00
Matt Morehouse bb3a3da38d [DFSan] Don't unmap during dfsan_flush().
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
2020-08-14 11:43:49 -07:00
Julian Lettner d137db8029 [TSan][libdispatch] Add interceptors for dispatch_async_and_wait()
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
2020-08-14 09:39:57 -07:00
Matt Morehouse c1f9c1c13c [DFSan] Fix parameters to strtoull wrapper.
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
2020-08-14 08:02:30 -07:00
Chris Kennelly 800f0eda5b [NFC] Remove unused function.
Differential Revision: https://reviews.llvm.org/D85944
2020-08-13 21:20:15 -04:00
Chris Kennelly 097c8fb2cb [NFC] Remove unused variables.
These were no longer needed following
96855125e7.

Reviewed By: rupprecht

Differential Revision: https://reviews.llvm.org/D85939
2020-08-13 17:56:51 -04:00
Peter Collingbourne 9f8c4039f2 sanitizer_common: Introduce internal_madvise and start using it.
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
2020-08-13 13:09:02 -07:00
Chris Kennelly 96855125e7 [tsan] Respect no_huge_pages_for_shadow.
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
2020-08-13 15:55:23 -04:00
Dávid Bolvanský 3944d3df4f [Tests] Removed debug copy command 2020-08-13 20:21:19 +02:00
Dávid Bolvanský 50c743fa71 [BPI] Improve static heuristics for integer comparisons
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
2020-08-13 19:54:27 +02:00
Rainer Orth 55e472e9da [compiler-rt][asan][test] Skipt sanitizer_common tests on Sparc
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
2020-08-13 10:20:52 +02:00
Ilya Leoshkevich eca4b4007d [Sanitizer] Fix segfaults during unwinding on SystemZ
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
2020-08-12 22:24:32 +02:00
Matt Morehouse fd893bda55 Fix sigaction interceptor to always correctly populate oldact
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
2020-08-12 10:11:56 -07:00
Ilya Leoshkevich f5a252ed68 [SanitizerCoverage] Use zeroext for cmp parameters on all targets
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
2020-08-12 18:38:12 +02:00
Petr Hosek 31e5f7120b [CMake] Simplify CMake handling for zlib
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
2020-08-11 20:22:11 -07:00
Ilya Leoshkevich 9df7ee34e1 [libFuzzer] Fix minimizing timeouts
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
2020-08-11 22:16:12 +02:00
Julian Lettner bfb0b853b2 [compiler-rt] XFAIL test on iOS
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
2020-08-11 11:58:40 -07:00
Rainer Orth dc7630dd44 [compiler-rt][builtins] Un-xfail two tests on sparcv9
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
2020-08-11 15:47:17 +02:00
Rainer Orth 8144a7d8fc [compiler-rt][ubsan][test] Fix TypeCheck/misaligned.cpp on Sparc
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
2020-08-11 12:46:34 +02:00
Gui Andrade c0b5000bd8 [MSAN RT] Use __sanitizer::mem_is_zero in __msan_test_shadow
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
2020-08-10 19:22:27 +00:00
Petr Hosek a4d78d23c5 Revert "[CMake] Simplify CMake handling for zlib"
This reverts commit ccbc1485b5 which
is still failing on the Windows MLIR bots.
2020-08-08 17:08:23 -07:00
Petr Hosek ccbc1485b5 [CMake] Simplify CMake handling for zlib
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
2020-08-08 16:44:08 -07:00
Teresa Johnson bb1456decf [sanitizer] Fix comment (NFC)
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.
2020-08-07 16:18:18 -07:00