This patch defines `config.apple_platform_min_deployment_target_flag`
in the ASan, LibFuzzer, TSan, and UBSan lit test configs.
rdar://problem/59463146
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.
Reviewers: pcc
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69405
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
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
Unlike asan, which isn't supported yet on 64-bit Solaris/x86, there's no reason to disable
ubsan. This patch does that, but keeps the 64-bit ubsan-with-asan tests disabled.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D63982
llvm-svn: 365302
These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
llvm-svn: 364591
This caused Chromium's clang package to stop building, see comment on
https://reviews.llvm.org/D61242 for details.
> Summary:
> 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 second 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.
>
> rdar://problem/50124489
>
> Reviewers: kubamracek, yln, vsk, juliehockett, phosek
>
> Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits
>
> Tags: #llvm, #sanitizers
>
> Differential Revision: https://reviews.llvm.org/D61242
llvm-svn: 363779
Summary:
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 second 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.
rdar://problem/50124489
Reviewers: kubamracek, yln, vsk, juliehockett, phosek
Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61242
llvm-svn: 363633
In particular, don't call get_target_flags_for_arch() since that
will cause an error in some situations:
If DARWIN_iossim_ARCHS=i386;x86_64, DARWIN_osx_ARCHS=x86_64, and
DARWIN_iossym_SYSROOT isn't set (due to the simulator sysroot not being
available), then config-ix.cmake won't add i386 to COMPILER_RT_SUPPORTED_ARCH
but ubsan's test/CMakeLists.txt would call get_target_flags_for_arch()
with i386, which would then run into the error in
get_target_flags_for_arch().
Having these conditions isn't ideal. The background here is that we
configure our mac-hosted trunk bots all the same (so they all have the
same DARWIN_*_archs, and we don't easily know if a mac host bot is
targeting mac or ios at the place where we call cmake), but only the
ios-targeting bots have ios sysroots available.
This will hopefully unbreak that use case without impacting anything
else -- and it makes ubsan and asan test setup more alike.
llvm-svn: 362010
This reverts commit 1bcdbd68616dc7f8debe126caafef7a7242a0e6b.
It's been reported that some bots are failing with this change with CMake
error like:
```
CMake Error at /b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:177 (message):
Unsupported architecture: arm64
Call Stack (most recent call first):
/b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:216 (get_target_flags_for_arch)
/b/s/w/ir/k/llvm-project/compiler-rt/test/tsan/CMakeLists.txt:78 (get_test_cflags_for_apple_platform)
```
I'm reverting the patch now to unbreak builds. I will investigate properly when time permits.
rdar://problem/50124489
llvm-svn: 359327
platforms.
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.
rdar://problem/50124489
Differential Revision: https://reviews.llvm.org/D58578
llvm-svn: 359305
of a darwin platform was in the list of `UBSAN_SUPPORTED_ARCH`.
This is a follow up to r341306.
The typo meant that if an architecture was a prefix to another
architecture in the list (e.g. `armv7` is a prefix of `armv7k`) then
this would trigger a match which is not the intended behaviour.
rdar://problem/41126835
llvm-svn: 342553
tests for ios, watchos, tvos, and their simulator counterparts.
This commit does not make the tests actually pass. This will be handled
in later commits.
rdar://problem/41126835
Differential Revision: https://reviews.llvm.org/D51270
llvm-svn: 341306
Summary:
This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
* For the time being, the port is for 32-bit x86 only, so reject the various tests on
x86_64.
* When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares
_setjmp and _longjmp inside namespace std.
* MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a
no-op compat define, Solaris does not.
* test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working
directory which failed as observed. cd'ing out of the dir before let the test pass.
* Two tests needed a declaration of alloca. I've now copied the existing code from
test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and
maintainable to have a common testsuite header where such code is collected.
* Similarly, Solaris' printf %p format doesn't include the leading 0x.
* In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__
(predefined by clang for no apparent reason) to avoid conflicting declarations
for memalign.
* test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent
ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and
friends as predefined by clang and gcc?
Patch by Rainer Orth.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40900
llvm-svn: 322635
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
As a follow-up to r315142, this makes it possible to use ubsan with a
static runtime on Darwin. I've also added a new StandaloneStatic testing
configuration so the new setup can be tested.
llvm-svn: 315143
Summary:
Enable check-cfi and check-ubsan on Android.
Check-ubsan includes standalone and ubsan+asan, but not tsan or msan.
Cross-dso cfi tests are disabled for now.
Reviewers: vitalybuka, pcc
Subscribers: srhines, kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38608
llvm-svn: 315105
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
It's fixing compilation errors. The runtime is not yet working.
Missing features:
OverrideFunction for x64
an equiv function for inline asm (atomic_compare_exchange_strong)
shadow memory offset needs to be adjusted
RoundUpToInstrBoundary for x64
They will be implemented by subsequent patches.
Patch by Wei Wang.
Differential revision: http://reviews.llvm.org/D20455
llvm-svn: 271049
Summary:
Rather than having to add new "experimental" options each time someone wants to work on bringing a sanitizer to a new platform, this patch makes options for all of them.
The default values for the options are set by the platform checks that would have enabled them, but they can be overridden on or off.
Reviewers: kubabrecka, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14846
llvm-svn: 255170
Without the --target flag, clang uses the mips64 triple which selects the n64 abi. We need to add --target=mips-linux-gnu, so that clang can select the correct abi for mips32r2.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9249
llvm-svn: 237675
Embed UBSan runtime into TSan and MSan runtimes in the same as we do
in ASan. Extend UBSan test suite to also run tests for these
combinations.
llvm-svn: 235954
a given platform in a top-level CMakeLists.txt to use it both
in lib/ and in test/ subdirectories. Move architecture/platform
checks to config-ix.
llvm-svn: 215247
You can expect the sanitizers to be built under any of the following conditions:
1) CMAKE_C_COMPILER is GCC built to cross-compile to ARM
2) CMAKE_C_COMPILER is Clang built to cross-compile to ARM (ARM is default target)
3) CMAKE_C_COMPILER is Clang and CMAKE_C_FLAGS contains -target and --sysroot
Differential Revision: http://reviews.llvm.org/D3794
llvm-svn: 209835
Dan Liew