This option disables the validation of binary UUIDs. This is useful
in environments where the `otool` binary is not available.
rdar://problem/49476995
llvm-svn: 367379
Two SPARC builtins tests are currently FAILing due to codegen bugs:
Builtins-sparc-sunos :: divtc3_test.c
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
I'd like to XFAIL them to reduce testsuite noise.
Done as follows, tested on sparcv9-sun-solaris2.11 and x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64796
llvm-svn: 367295
AddressSanitizer-*-sunos :: TestCases/intercept-rethrow-exception.cc currently FAILs
on Solaris. This happens because std::rethrow_exception cannot be intercepted, as
detailed in Bug 42703.
To account for this and reduce testsuite noise, this patch XFAILs the test.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D65056
llvm-svn: 367293
Second attempt.
Haven't found a better way to pass the libcxx include path for building
compiler-rt with libcxx; this seems to be missing only for xray.
Differential Revision: https://reviews.llvm.org/D65307
llvm-svn: 367250
Haven't found a better way to pass the libcxx include path for building
compiler-rt with libcxx; this seems to be missing only for xray.
Differential Revision: https://reviews.llvm.org/D65307
llvm-svn: 367239
Summary:
If XCode is not installed, `xcodebuild -version -sdk macosx Path` will give
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
In this case the variable OSX_SYSROOT will be empty and
OSX_SYSROOT_FLAG is set to "-isysroot" (without a path).
This then causes the CompilerRTUnitTestCheckCxx target failed to for me
because "${COMPILER_RT_TEST_COMPILER} ${OSX_SYSROOT_FLAG} -E" expanded to
"clang -isysroot -E". This results in a warning "sysroot -E does not exist"
and the target fails to run because the C++ headers cannot be found.
Reviewers: beanz, kubamracek
Reviewed By: beanz
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65323
llvm-svn: 367170
Summary:
In Android, attempting to mkdir() or even stat() top-level directories
like /data causes noisy selinux denials. During whole-system coverage
instrumentation, this causes a deluge of noisy messages that drown out
legitimate selinux denials, that should be audited and fixed.
To avoid this, skip creating any directory in GCOV_PREFIX (thereby
assuming that it exists).
- Android platform ensures that the GCOV_PREFIX used in Android is
created and read/writable by all processes.
- This only affects the Android platform (by checking against
__ANDROID_API_FUTURE__) and for apps built with Clang coverage, the
runtime will still create any non-existent parent directories for the
coverage files.
Reviewers: srhines, davidxl
Subscribers: krytarowski, #sanitizers, danalbert, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65245
llvm-svn: 367064
Summary:
Make SymbolizerProcess::StartSymbolizerSubprocess virtual and protected
to allow subclasses to customize it via "override and call".
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65252
llvm-svn: 366967
Summary:
This introduces a bunch of small optimizations with the purpose of
making the fastpath tighter:
- tag more conditions as `LIKELY`/`UNLIKELY`: as a rule of thumb we
consider that every operation related to the secondary is unlikely
- attempt to reduce the number of potentially extraneous instructions
- reorganize the `Chunk` header to not straddle a word boundary and
use more appropriate types
Note that some `LIKELY`/`UNLIKELY` impact might be less obvious as
they are in slow paths (for example in `secondary.cc`), but at this
point I am throwing a pretty wide net, and it's consistant and doesn't
hurt.
This was mosly done for the benfit of Android, but other platforms
benefit from it too. An aarch64 Android benchmark gives:
- before:
```
BM_youtube/min_time:15.000/repeats:4/manual_time_mean 445244 us 659385 us 4
BM_youtube/min_time:15.000/repeats:4/manual_time_median 445007 us 658970 us 4
BM_youtube/min_time:15.000/repeats:4/manual_time_stddev 885 us 1332 us 4
```
- after:
```
BM_youtube/min_time:15.000/repeats:4/manual_time_mean 415697 us 621925 us 4
BM_youtube/min_time:15.000/repeats:4/manual_time_median 415913 us 622061 us 4
BM_youtube/min_time:15.000/repeats:4/manual_time_stddev 990 us 1163 us 4
```
Additional since `-Werror=conversion` is enabled on some platforms we
are built on, enable it upstream to catch things early: a few sign
conversions had slept through and needed additional casting.
Reviewers: hctim, morehouse, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, javed.absar, kristof.beyls, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64664
llvm-svn: 366918
Summary:
Looks like a typo, as that function actually returns void and is used
as such in libFuzzer code as well.
Reviewers: kcc, Dor1s
Reviewed By: Dor1s
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65160
llvm-svn: 366834
While working on https://reviews.llvm.org/D40900, two tests were failing since __clear_cache
aborted. While libgcc's __clear_cache is just empty, this only happens because
gcc (in gcc/config/sparc/sparc.c (sparc32_initialize_trampoline, sparc64_initialize_trampoline))
emits flush insns directly.
The following patch mimics that.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64496
llvm-svn: 366822
Under certain execution conditions, the `not` command binds to the command the
output is piped to rather than the command piping the output. In this case, that
flips the return code of the FileCheck invocation, causing a failure when
FileCheck succeeds.
llvm-svn: 366805
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
llvm-svn: 366447
It turns out that this test was only passing by accident. It was relying on
the optimizer to remove the only reference to A's vtable by realizing that
the CFI check will always fail. The vtable contains a reference to RTTI in
libc++, which will be unresolved because the C driver won't link against it.
This was found by my prototype implementation of HWASAN for globals, which
happens to end up preserving the reference.
Differential Revision: https://reviews.llvm.org/D64890
llvm-svn: 366389
On Darwin, the man page states that "both fputs() and puts() print
`(null)' if str is NULL."
rdar://48227136
Reviewed By: Lekensteyn
Differential Revision: https://reviews.llvm.org/D64773
llvm-svn: 366342
Summary:
Adds thread ID to PRNG seed for increased entropy. In particular, this allows
multiple runs in quick succession that will have different PRNG seeds, allowing
for better demos/testing.
Reviewers: kcc
Reviewed By: kcc
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D64453
llvm-svn: 366253
i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b:
* Bump the function_type_mismatch handler version, as its signature has changed.
* The function_type_mismatch handler can return successfully now, so
SanitizerKind::Function must be AlwaysRecoverable (like for
SanitizerKind::Vptr).
* But the minimal runtime would still unconditionally treat a call to the
function_type_mismatch handler as failure, so disallow -fsanitize=function in
combination with -fsanitize-minimal-runtime (like it was already done for
-fsanitize=vptr).
* Add tests.
Differential Revision: https://reviews.llvm.org/D61479
llvm-svn: 366186
RTL interception broke mingw32, this should fix those builds by
removing dependency on windows.h
reviewed in https://reviews.llvm.org/D64694
llvm-svn: 366105
This assembly is part of a macro that was reformatted in D60351.
The missing space between push and { results in:
Error: bad instruction `push{r4, r5,r6,lr}'
llvm-svn: 365957
This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward:
- Add 32 and 64-bit sparc to compiler-rt
- lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc)
There's one issue of note: many asan tests fail to compile on Solaris/SPARC:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The
goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc,
which doesn't have the problem above and works just fine.
With this patch, sparcv9-sun-solaris2.11 test results are pretty good:
Failing Tests (9):
Builtins-sparc-sunos :: divtc3_test.c
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
[...]
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal
patches either currently in review or about to be submitted.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D40943
llvm-svn: 365880
The MemoryMappingLayout.DumpListOfModules currently FAILs on Solaris:
[ RUN ] MemoryMappingLayout.DumpListOfModules
/vol/llvm/src/compiler-rt/local/lib/sanitizer_common/tests/sanitizer_procmaps_test.cc:52: Failure
Value of: found
Actual: false
Expected: true
[ FAILED ] MemoryMappingLayout.DumpListOfModules (22 ms)
The problem is that the test expects the executable name from modules[i].full_name(),
however the pr_mapname field of struct prmap is just the entry in /proc/<pid>/object,
which is "a.out" instead of "Sanitizer-i386-Test". Fortunately, the real name can
be determined by looking in proc/<pid>/path where "a.out" is a symlink to the
real path.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64559
llvm-svn: 365879
Dan Liew