Neither the Illumos `ld` nor the Solaris 11.3 one support the `--version-script` and
`z gnu-linker-script-compat` options, which breaks the `compiler-rt` build.
This patch checks for both options instead of hardcoding their use.
Tested on `amd-pc-solaris2.11` (all of Solaris 11.4, 11.3, and Illumos).
Differential Revision: https://reviews.llvm.org/D84559
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
Otherwise if 'ld' is an older system LLD (FreeBSD; or if someone adds 'ld' to
point to an LLD from a different installation) which does not support the
current ModuleSummaryIndex::BitCodeSummaryVersion, the test will fail.
Add lit feature 'binutils_lto'. GNU ld is more common than GNU gold, so
we can just require 'is_binutils_lto_supported' to additionally support GNU ld.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D84133
Most of the code in compiler_rt is C code. However, clang_rt.profile
contains the InstrProfilingRuntime.cpp file, which builds as C++. This
means that including e.g. <stdint.h> will actually include libc++'s
<stdint.h> and then #include_next the system's <stdint.h>. However, if
the target we're building compiler-rt for isn't supported by libc++,
this will lead to a failure since libc++'s <stdint.h> includes <__config>,
which performs various checks.
Since the goal seems to *not* be including any header from the C++ Standard
Library in clang_rt.profile, using -nostdinc++ to ensure that doesn't
happen unknowingly seems to make sense.
rdar://65852694
Differential Revision: https://reviews.llvm.org/D84205
This uses a special set of flags given to unittests to work around warnings raised by googletest and googlemock. This should bring the sanitizer bots back to green.
For Android only, compiler-rt used detect_target_arch to select the
architecture to target. detect_target_arch was added in Sept 2014
(SVN r218605). At that time, compiler-rt selected the default arch
using ${LLVM_NATIVE_ARCH}, which seems to have been the host
architecture and therefore not suitable for cross-compilation.
The compiler-rt build system was refactored in Sept 2015 (SVN r247094
and SVN r247099) to use COMPILER_RT_DEFAULT_TARGET_TRIPLE to control
the target arch rather than LLVM_NATIVE_ARCH. This approach is simpler
and also works for Android cross-compilation, so remove the
detect_target_arch function.
Android targets i686, but compiler-rt seems to identify 32-bit x86 as
"i386". For Android, we were previously calling add_default_target_arch
with i386, and calling add_default_target_arch with i686 does not build
anything. i686 is not listed in builtin-config-ix.cmake,
ALL_BUILTIN_SUPPORTED_ARCH.
Differential Revision: https://reviews.llvm.org/D82148
Split filter_builtin_sources into two functions:
- filter_builtin_sources that removes generic files when an
arch-specific file is selected.
- darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE
lists (using the files in lib/builtins/Darwin-excludes).
darwin_filter_builtin_sources delegates to filter_builtin_sources.
Previously, lib/builtins/CMakeLists.txt had a number of calls to
filter_builtin_sources (with a confusing/broken use of the
`excluded_list` parameter), as well as a redundant arch-vs-generic
filtering for the non-Apple code path at the end of the file. Replace
all of this with a single call to filter_builtin_sources.
Remove i686_SOURCES. Previously, this list contained only the
arch-specific files common to 32-bit and 64-bit x86, which is a strange
set. Normally the ${ARCH}_SOURCES list contains everything needed for
the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH.
NFCI, but i686_SOURCES won't be defined, and the order of files in
${arch}_SOURCES lists will change.
Differential Revision: https://reviews.llvm.org/D82151
At this point in this code:
- COMPILER_RT_DEFAULT_TARGET_TRIPLE is "i686-linux-android"
- arch is "i386"
The get_compiler_rt_target function currently turns that into:
i686-android-linux-android
The ${COMPILER_RT_OS_SUFFIX} is "-android" and redundant, so stop
adding it.
The get_compiler_rt_target() function is used for the
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR mode that isn't normally used with
Android.
Differential Revision: https://reviews.llvm.org/D82150
Summary:
This patch implements dynamic stack allocation for the VE target. Changes:
* compiler-rt: `__ve_grow_stack` to request stack allocation on the VE.
* VE: base pointer support, dynamic stack allocation.
Differential Revision: https://reviews.llvm.org/D79084
When build in runtime bulid mode with LLVM_ENABLE_RUNTIMES,
the base-config-ix.cmake will complain about two errors.
One is empty string in replace, the other one is unknown `TEST_BIG_ENDIAN ` command.
This patch fix it so that we can test runtime build.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80040
Since setting COMPILER_RT_USE_BUILTINS_LIBRARY would remove -z,defs
flag, missing builtins library would continue to build unnoticed.
Explicitly emit an error in such case.
Differential Revision: https://reviews.llvm.org/D79470
Only add CMAKE_EXE_LINKER_FLAGS when in a standalone bulid.
Or else CMAKE_EXE_LINKER_FLAGS contains flags for build compiler of Clang/llvm.
This might not be the same as what the COMPILER_RT_TEST_COMPILER supports.
eg: the build compiler use lld linker and we use it to build clang with
default ld linker then to be tested clang will complain about lld
options like --color-diagnostics.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D78373
Summary:
When doing cross-compilation from Linux to MacOS we don't have
access to have access to `xcodebuild` and therefore need a way
to set the SDK version from the outside.
Fixes https://reviews.llvm.org/D68292#1853594 for me.
Reviewers: delcypher, yln
Reviewed By: delcypher
Subscribers: #julialang, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77026
https://github.com/apple/swift/pull/30112/ makes the Swift standard
library for iOS build for arm64e. If you're building Swift against your
own LLVM, this in turn requires having the builtins built for arm64e,
otherwise you won't be able to use the builtins (which will in turn lead
to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins
build for arm64e to fix this.
Differential Revision: https://reviews.llvm.org/D76041
Patch by Zhizhou Yang!
In his own words:
"""
Currently compiler-rt doesn't officially support either PGO
instrumentation or use PGO profdata to build it.
PGO related flags are passed into compiler-rt since rL372209, and
causing bugs: 45022, crbug:1018840
This patch adds several checks in compiler-rt to disable PGO related
flags and provides a flag to turn on PGO for compiler-rt if needed.
"""
Differential Revision: https://reviews.llvm.org/D75499
platforms.
For the simulators this changes the following compilation flags (
used both for building the runtime and lit tests).
iOS simulator: `-miphoneos-version-min` -> `-mios-simulator-version-min`
watchOS simulator: `-mwatchos-version-min` -> `-mwatchos-simulator-version-min`
tvOS simulator: `-mtvos-version-min` -> `-mtvos-simulator-version-min`
rdar://problem/59463146
XRay builds uses llvm-config to obtain the ldflags and libs and then
passes those to CMake. Unfortunately, this breaks on Windows because
CMake tries to interpret backslashes followed by certain characters
as flags. We need to rewrite these into forward slashes that are used
by CMake (even on Windows).
Differential Revision: https://reviews.llvm.org/D73523
Summary:
Since commit c299d1981d scudo
standalone can't be built without including sys/auxv.h.
I do not have that file on my system, and my builds have failed
when trying to simply build "all" runtimes. Assuming that "all"
means "all possible given the current environment" we need to
guard the setting of COMPILER_RT_HAS_SCUDO_STANDALONE=TRUE by
first checking if sys/auxv.h can be found.
Reviewers: pcc, cryptoad
Reviewed By: pcc
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73631
Summary:
In order to do this `FUZZER_SUPPORTED_OS` had to be pulled out of
`lib/fuzzer/CMakeLists.txt` and into the main config so we can use it
from the `test/fuzzer/CMakeList.txt`. `FUZZER_SUPPORTED_OS` currently
has the same value of `SANITIZER_COMMON_SUPPORTED_OS` which preserves
the existing behaviour but this allows us in the future to adjust the
supported platforms independent of `SANITIZER_COMMON_SUPPORTED_OS`. This
mirrors the other sanitizers.
For non-Apple platforms `FUZZER_SUPPORTED_OS` is not defined and
surprisingly this was the behaviour before this patch because
`SANITIZER_COMMON_SUPPORTED_OS` was actually empty. This appears to
not matter right now because the functions that take an `OS` as an
argument seem to ignore it on non-Apple platforms.
While this change tries to be NFC it is technically not because we
now generate an iossim config whereas previously we didn't. This seems
like the right thing to do because the build system was configured to
compile LibFuzzer for iossim but previously we weren't generating a lit
test config for it. The device/simulator testing configs don't run by
default anyway so this shouldn't break testing.
This change relies on the get_capitalized_apple_platform() function
added in a previous commit.
rdar://problem/58798733
Reviewers: kubamracek, yln
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73243
Summary:
The previous code hard-coded platform names but compiler-rt's CMake
build system actually already knows which Apple platforms ASan supports.
This change uses this information to enumerate the different Apple
platforms.
rdar://problem/58798733
Reviewers: kubamracek, yln
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73232
On Darwin, part of the profile runtime is included in the builtin
library. f35032e changed the location of InstrProfData.inc but the
builtin build for Darwin hasn't been updated to include the new
path which causes a breakage when building for Darwin. This change
addresses this breakage.
Bump default value for `-miphoneos-version-min=x` to 9.0 (from 8.0).
TSan tests that use thread local storage `__thread` (e.g., tls_race.cpp)
are failing to link for the iOS simulator (arch=x86_64 and
-miphoneos-version-min=8.0) on internal/master (will be submitted to
Glacier train):
```
ld: targeted OS version does not support use of thread local variables in _main for architecture x86_64
```
iOS 9.0 was released 2015.
Bump default value for `SANITIZER_MIN_OSX_VERSION` to 10.10 (from 10.9).
TSan does not work on macOS 10.9 and a nice error message is preferable
to an "unreferenced symbol" error when loading the TSan runtime.
We could try to only bump the deployment target for TSan, but we would
have to invest into adding support for this to our CMake build and it
does not seem worth it. macOS 10.10 was released in 2014.
rdar://31335781
This allows crtbegin and crtend to be built, allowing RISC-V
to no longer rely on implementations from libgcc.
Differential revision: https://reviews.llvm.org/D68393
D69405 causes failure if running LIT when the compiler was built without lld.
Patch by Anh Tuyen Tran (anhtuyen)
Differential Revision: https://reviews.llvm.org/D69685
Summary:
xcodebuild does not work unless XCode is installed whereas xcrun also work
when only the Command Line Tools are installed. Unlike the check for the
version (D69610), this did not cause an erro for me since the fallback to
/usr/include for the OSX sysroot worked.
Reviewers: yln, delcypher
Reviewed By: yln
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69659
Summary:
Starting with 8a5bfbe6db (D68292) this file
unconditionally uses xcodebuild to get the SDK version. On my system this
always fails with
`xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance`
Reviewers: delcypher, yln
Reviewed By: delcypher, yln
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69610
In cmake, if TEST_COMPILE_ONLY is set
compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake invokes try_compile_only()
but try_compile_only() is defined in BuiltinTests.cmake and is not included in
CompilerRTDarwinUtils.cmake. This patch simply includes it BuiltinTests.
Differential Revision: https://reviews.llvm.org/D69410
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
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, dyung
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69196
llvm-svn: 375472
Summary:
In the macOS 10.15 SDK the ability to link i386 binaries was removed and
in the corresponding OS it is not possible to run macOS i386 binaries.
The consequence of these changes meant that targets like `check-asan`
would fail because:
* Unit tests could not be linked for i386
* Lit tests for i386 would fail due to not being able to execute
compiled binaries.
The simplest fix to this is to simply disable building for i386 for
macOS when using the 10.15 SDK (or newer). This disables building the
i386 slice for most compiler-rt libraries and consequently disables the
unit and lit tests for macOS i386.
Note that because the `DARWIN_osx_ARCHS` CMake variable is a cache
variable this patch will have no affect on existing builds unless
the existing cache variable is deleted. The simplest way to deal with
this is delete existing builds and just do a fresh configure.
Note this should not affect the builtins which are managed with
the `DARWIN_osx_BUILTIN_ARCHS` CMake cache variable.
For those who wish to force using a particular set of architectures when
using newer SDKs passing `-DDARWIN_osx_ARCHS=i386;x86_64;x86_64h` to
CMake should provide a usable (but completely unsupported) workaround.
rdar://problem/55668535
rdar://problem/47939978
Reviewers: kubamracek, yln, azhar, kcc, dvyukov, vitalybuka, cryptoad, eugenis, thakis, phosek
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D68292
llvm-svn: 374977
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
After r372209, the compile command can end up including an argument with
quotes in it, e.g.
-fprofile-instr-use="/foo/bar.profdata"
when invoking the compiler with execute_process, the compiler ends up
getting that argument with quotes and all, and fails to open the file.
This all seems horribly broken, but one way of working around it is to
simply strip the quotes from the string here. If they were there to
protect a path that's got spaces in it, that wasn't going to work
anyway because the string is later split by spaces.
llvm-svn: 372312
Summary:
If the cache variable named in `${valid_archs}` (e.g. `DARWIN_osx_BUILTIN_ARCHS`)
is set in the cache but is empty then the cache check
`if(${valid_archs})` will be false so the function will probe the
compiler but the `set(...)` command at the end of the function to update
the cache variable will be a no-op. This is because `set(...)` will not
update an existing cache variable unless the `FORCE` argument is
provided.
To fix this this patch adds `FORCE` so the cache is always updated.
rdar://problem/55323665
Reviewers: vsk, kubamracek
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67530
llvm-svn: 371872
built-ins from the rest of compiler-rt.
The detection of supported platform (os) architectures for Darwin relies
on the `darwin_test_archs()` CMake function. This is used both for
building the builtins (`builtin-config-ix.cmake`) and for the rest of
the compiler-rt (`config-ix.cmake`).
`darwin_test_archs()` implements a cache, presumably to speed up CMake
re-configures. Unfortunately this caching is buggy because it depends
on external global state (i.e. the `TEST_COMPILE_ONLY` variable) and
this is not taken into account. For `config-ix.cmake`
`TEST_COMPILE_ONLY` is not set and for `builtin-config-ix.cmake`
`TEST_COMPILE_ONLY` is set to `On`. This makes the
`darwin_test_archs()` function racey in the sense that a call from one
calling context will poison the cache for the other calling context.
This is actually an issue George Karpenkov discovered a while back
and had an incomplete patch for (https://reviews.llvm.org/D45337)
but this was never merged.
To workaround this, this patch switches to using a different set of
variables for the platform architecture builtins, i.e.
`DARWIN_<OS>_ARCHS` -> `DARWIN_<OS>_BUILTIN_ARCHS`. This avoids the
cache poisoning problem because the cached variable names are different.
This also has the advantage that the the configured architectures for
builtins and the rest of the compiler-rt are now independent and
can be set differently if necessary.
Note in `darwin_test_archs()` we also now pass `-w` to the compiler
because `try_compile_only()` treats compiler warnings as errors. This
was extremely fragile because compiler warnings (can easily appear due
to a buggy compiler or SDK headers) would cause compiler-rt to think an
architecture on Darwin wasn't supported.
rdar://problem/48637491
llvm-svn: 371871
When cross-compiling compiler-rt as part of LLVM e. g. for Linux on
a Windows host and using the just-built clang as cross-compiler, we set
the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level
cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty
string in the nested cmake invocation for building builtins.
But the compiler for compiling test cases is meant to be run on host,
therefore it may have the '.exe' suffix.
Handle this by asking cmake about the host system.
Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com>
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D67401
llvm-svn: 371754
- recent commit https://reviews.llvm.org/D66433 enabled libfuzzer
to build on windows, this just enables the option to build as part
of the the regular build.
llvm-svn: 370390
Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards
the new features behind it.
This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66.
llvm-svn: 369527
Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should
become `COMPILER_RT_HAS_STD_CXX14_FLAG`.
I ran into this issue when replacing llvm::make_unique with
std::make_unique in an X-ray unit test. We are correctly passing
`-std=c++14`, but this got overwritten further down the invocation by
the compiler-rt flags. Given that this unit test is using LLVM headers,
this is bound to break sooner than later, regardless of my change.
Differential revision: https://reviews.llvm.org/D66271
llvm-svn: 368960
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
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
Summary:
Combine few relatively small changes into one:
- implement internal_ptrace() and internal_clone() for NetBSD
- add support for stoptheworld based on the ptrace(2) API
- define COMPILER_RT_HAS_LSAN for NetBSD
- enable tests for NetBSD/amd64
Inspired by the original implementation by Christos Zoulas in netbsd/src for GCC.
The implementation is in theory CPU independent through well defined macros
across all NetBSD ports, however only the x86_64 version was tested.
Reviewers: mgorny, dvyukov, vitalybuka, joerg, jfb
Reviewed By: vitalybuka
Subscribers: dexonsmith, jfb, srhines, kubamracek, llvm-commits, christos
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64057
llvm-svn: 365735
Remove ARM32/ARM64 support for GWP-ASan due to a strange SEGV when
running scudo's preinit.c test. Disabling to make the bots go green
while investigating.
llvm-svn: 364486
Summary:
Specify message levels in CMake. Prefer STATUS (stdout).
As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step.
This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default.
* I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations.
* Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know.
Patch by: Christoph Siedentop
Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz
Reviewed By: sgraenitz
Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits
Tags: #sanitizers, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D63370
llvm-svn: 363821
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
Since updating the SystemZ LLVM build bot system to Ubuntu 18.04, all bots
are red due to two ASAN failures. It turns out these are triggered due to
building the ASAN support libraries, in particular the interceptor routines
using GCC 7. Specifically, at least on our platform, this compiler decides
to "partially inline" some of those interceptors, creating intermediate
stub routines like "__interceptor_recvfrom.part.321". These will show up
in the backtraces at interception points, causing testsuite failures.
As a workaround to get the build bots green again, this patch adds the
-fno-partial-inlining command line option when building the common
sanitizer support libraries on s390x, if that option is supported by
the compiler.
llvm-svn: 363679
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
The default nm executable may not be able to handle the architecture
we're building the sanitizers for. Respect CMAKE_NM if it's set to
ensure we're using the correct nm tool. Preserve the existing NM
environment variable override to not break its users.
Differential Revision: https://reviews.llvm.org/D63368
llvm-svn: 363483
compiler-rt already uses libtool instead of ar when building for
Apple platform, but that's not being used when builtins are being
built separately e.g. as part of the runtimes build. This change
extracts the logic setting up libtool into a separate file and uses
it from both the compiler-rt and standalone builtins build.
Differential Revision: https://reviews.llvm.org/D62820
llvm-svn: 362466
This is a follow up to r361432, changing the layout of per-target
runtimes to more closely resemble multiarch. While before, we used
the following layout:
[RESOURCE_DIR]/<target>/lib/libclang_rt.<runtime>.<ext>
Now we use the following layout:
[RESOURCE_DIR]/lib/<target>/libclang_rt.<runtime>.<ext>
This also more closely resembles the existing "non-per-target" layout:
[RESOURCE_DIR]/lib/<os>/libclang_rt.<runtime>-<arch>.<ext>
This change will enable further simplification of the driver logic
in follow up changes.
Differential Revision: https://reviews.llvm.org/D62469
llvm-svn: 361784
This is needed when using compiler wrappers such as ccache or distcc
and should address the failure on clang-x86_64-debian-fast bot.
Differential Revision: https://reviews.llvm.org/D62104
llvm-svn: 361111
When MIPS 32-bit compiler-rt is building on 32-bit host or using 32-bit
`DLLVM_HOST_TRIPLE` the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64`
macros defined by statements from the `HandleLLVMOptions.cmake`. In case
of building 32-bit libraries on 64-bit host using default host triple
these macros are not defined. As a result assertions check a consistency
between the `struct_kernel_stat_sz` constant and the `struct_kernel_stat_sz`
start to fail.
To resolve this problem and enable building both 32/64-bit versions
of MIPS compiler-rt libraries on 64-bit host at once always explicitly
define the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros
for MIPS 32-bit.
llvm-svn: 360825
Summary:
See D60593 for further information.
This patch slices off the PRNG implementation and the initial build files for GWP-ASan.
Reviewers: vlad.tsyrklevich, morehouse, vitalybuka
Reviewed By: morehouse
Subscribers: srhines, kubamracek, mgorny, #sanitizers, llvm-commits, cryptoad, eugenis
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61867
llvm-svn: 360710
The source uses C11 syntax such as comments and some compilers print
warnings without specifying this flag.
Differential Revision: https://reviews.llvm.org/D61797
llvm-svn: 360459
Darwin targets were generating CMake install rules but not the
corresponding install targets. Centralize the existing install target
creation to a function and use that function for both Darwin and
non-Darwin builds.
Differential Revision: https://reviews.llvm.org/D61541
llvm-svn: 360181
As it is not implemented upon usage, it just provokes numerous linkage issues so better switch off clearly.
Reviewers: vitalybuka, morehouse
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D61484
llvm-svn: 359920
Summary:
Re-enable libFuzzer on i386 Linux after it was accidentally
disabled.
Also disable gc-sections.test on i386 since lld isn't
garbage collecting properly with ASAN on i386.
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: srhines, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61415
llvm-svn: 359802
The initial implementation didn't properly support cross-compilation
via the runtime build, the updated implementation should address that
by expanding the CMAKE_C_COMPILE_OBJECT variable with correct values.
Differential Revision: https://reviews.llvm.org/D61356
llvm-svn: 359644
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359591
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359576
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
Summary:
Since neither compiler-rt nor the libc++ we build use exceptions, we
don't need libc++abi to have them either.
This resolves an issue where libFuzzer's private libc++ contains
implementations for __cxa_throw and friends, causing fuzz targets built
with their own C++ library to segfault during exception unwinding.
See https://github.com/google/oss-fuzz/issues/2328.
Reviewers: phosek, EricWF, kcc
Reviewed By: phosek
Subscribers: kcc, dberris, mgorny, christof, llvm-commits, metzman
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61053
llvm-svn: 359218
Summary:
There were existing calls to `try_compile_only()` with arguments not
prefixed by `SOURCE` or `FLAGS`. These were silently being ignored.
It looks like the `SOURCE` and `FLAGS` arguments were first introduced
in r278454.
One implication of this is that for a builtins only build for Darwin
(see `darwin_test_archs()`) it would mean we weren't actually passing
`-arch <arch>` to the compiler). This would result in compiler-rt
claiming all supplied architectures could be targetted provided
the compiler could build for Clang's default architecture.
This patch fixes this in several ways.
* Fixes all incorrect calls to `try_compile_only()`.
* Adds code to `try_compile_only()` to check for unhandled arguments
and raises a fatal error if this occurs. This should stop any
incorrect calls in the future.
* Improve the documentation on `try_compile_only()` which seemed
completely wrong.
rdar://problem/48928526
Reviewers: beanz, fjricci, dsanders, kubamracek, yln, dcoughlin
Subscribers: mgorny, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59429
llvm-svn: 356295
When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library
now has a dependency on the blocks runtime and libdispatch. Make sure we
set all the required linking options.
Also add cmake options for specifying additional library paths to
instruct the linker where to search for libdispatch and the blocks
runtime. This allows us to build TSan runtime with libdispatch support
without installing those libraries into default linker library paths.
`CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid
aborting the build due to failing the link step in CMake's
check_c_compiler test.
Reviewed By: dvyukov, kubamracek
Differential Revision: https://reviews.llvm.org/D59334
llvm-svn: 356281
It hasn't seen active development in years, and it hasn't reached a
state where it was useful.
Remove the code until someone is interested in working on it again.
Differential Revision: https://reviews.llvm.org/D59133
llvm-svn: 355862
Summary:
ShadowCallStack on x86_64 suffered from the same racy security issues as
Return Flow Guard and had performance overhead as high as 13% depending
on the benchmark. x86_64 ShadowCallStack was always an experimental
feature and never shipped a runtime required to support it, as such
there are no expected downstream users.
Reviewers: pcc
Reviewed By: pcc
Subscribers: mgorny, javed.absar, hiraditya, jdoerfert, cfe-commits, #sanitizers, llvm-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D59034
llvm-svn: 355624
This is another follow up to r354212 which is broken on Darwin when
cross-compiling runtimes to Linux when it ignores the -fuse-ld=lld
linker flag and attempts to use the host linker when performing the
compiler identification. Upon investigation, I noticed that setting
the project with appropriate list of languages makes the error go
away and it shouldn't hurt either.
Differential Revision: https://reviews.llvm.org/D58372
llvm-svn: 354350
This changes add_custom_libcxx to also build libcxxabi and merges
the two into a static and hermetic library.
There are multiple advantages:
1) The resulting libFuzzer doesn't expose C++ internals and looks
like a plain C library.
2) We don't have to manually link in libstdc++ to provide cxxabi.
3) The sanitizer tests cannot interfere with an installed version
of libc++.so in LD_LIBRARY_PATH.
Differential Revision: https://reviews.llvm.org/D58013
llvm-svn: 354212
Otherwise this propagates all the way to CMake and results in an error
during configuration. We check and handle the result and report warning
separately so this is not changing the behavior.
Differential Revision: https://reviews.llvm.org/D58086
llvm-svn: 353784
We shouldn't be treating runtimes builds as standalone builds since
we have enough of the context loaded into the runtimes environment.
Differential Revision: https://reviews.llvm.org/D57992
llvm-svn: 353601
Summary:
The motivating use case is eliminating duplicate profile data registered
for the same inline function in two object files. Before this change,
users would observe multiple symbol definition errors with VC link, but
links with LLD would succeed.
Users (Mozilla) have reported that PGO works well with clang-cl and LLD,
but when using LLD without this static registration, we would get into a
"relocation against a discarded section" situation. I'm not sure what
happens in that situation, but I suspect that duplicate, unused profile
information was retained. If so, this change will reduce the size of
such binaries with LLD.
Now, Windows uses static registration and is in line with all the other
platforms.
Reviewers: davidxl, wmi, inglorion, void, calixte
Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D57929
llvm-svn: 353547
Summary:
I mistakenly used a SCUDO variable instead of SCUDO_STANDALONE one. The net
result was that there were more architecture supported than I intended.
Correct that, I'll add more architectures once the bots are enabled and
green for x86.
Reviewers: eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D57897
llvm-svn: 353528
There's no need to expose these dependencies to consumers. This
matches the change made to other runtimes in D57456.
Differential Revision: https://reviews.llvm.org/D57873
llvm-svn: 353376
Summary:
This is the initial check-in for the Standalone version of Scudo.
The project is initially going to live in scudo/standalone then will
replace scudo. See http://lists.llvm.org/pipermail/llvm-dev/2019-January/129113.html
for details.
This initial CL is meant to lay out the project structure, of both
code & tests, providing a minimal amount of functionalities, namely
various definitions, some atomic helpers and an intrusive list.
(empty.cc is just here to have a compilation unit, but will go away
in the upcoming CLs).
Initial support is restricted to Linux i386 & x86_64 in make files
and will be extended once things land & work.
We will grow organically from here, adding functionalities in limited
amounts.
Reviewers: morehouse, eugenis, vitalybuka, kcc, mcgrathr, flowerhack
Reviewed By: morehouse, vitalybuka
Subscribers: srhines, mgorny, krytarowski, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D57412
llvm-svn: 353055
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
llvm-svn: 352341
Summary:
As reported on llvm-testers, during 8.0.0-rc1 testing I got errors while
building of `XRayTest`, during `check-all`:
```
[100%] Generating XRayTest-x86_64-Test
/home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace'
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors.
gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2
gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
gmake[1]: Target 'check-all' not remade because of errors.
gmake: *** [Makefile:277: check-all] Error 2
[Release Phase3] check-all failed
```
This is because the `backtrace` function requires `-lexecinfo` on BSD
platforms. To fix this, detect the `execinfo` library in
`cmake/config-ix.cmake`, and add it to the unit test link flags.
Additionally, since the code in `sys::PrintStackTrace` makes use of
`itaniumDemangle`, also add `-lLLVMDemangle`. (Note that this is more
of a general problem with libLLVMSupport, but I'm looking for a quick
fix now so it can be merged to the 8.0 branch.)
Reviewers: dberris, hans, mgorny, samsonov
Reviewed By: dberris
Subscribers: krytarowski, delcypher, erik.pilkington, #sanitizers, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D57181
llvm-svn: 352234
Summary:
Enable building libFuzzer with MSVC.
* Don't try to include <endian.h> in FuzzerSHA1.cpp. MSVC
doesn't have this header, and WINDOWS is always little
endian (even on ARM)
Subscribers: srhines, mgorny, javed.absar, kristof.beyls
Differential Revision: https://reviews.llvm.org/D56510
llvm-svn: 351855
Disable tests requiring sunrpc when the relevant headers are missing.
In order to accommodate that, move the header check
from sanitizer_common to base-config-ix, and define the check result
as a global variable there. Use it afterwards both for definition
needed by sanitizer_common, and to control 'sunrpc' test feature.
While at it, remove the append_have_file_definition macro that was used
only once, and no longer fits the split check-definition.
Bug report: https://github.com/google/sanitizers/issues/974
Differential Revision: https://reviews.llvm.org/D47819
llvm-svn: 351109
This makes the script a little more gn friendly; gn does not support
redirecting the output of a script.
Differential Revision: https://reviews.llvm.org/D56579
llvm-svn: 350980
Summary:
NetBSD uses typical UNIX interfaces.
All tests pass except instrprof-dlopen-dlclose-gcov.test, as there
is not supported semantics of atexit(3) in dlopen(3)ed+dlclose(3)d
DSO.
NetBSD also ships an older version of LLVM profile (ABI v.2 predating
ABI v.4 in upstream version) inside libc. That copy has been manually
removed during the porting and testing process of the upstream version
to NetBSD. Otherwise there were conflicts between them two.
Reviewers: joerg, vitalybuka, vsk
Subscribers: srhines, fedor.sergeev, llvm-commits, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D55997
llvm-svn: 349994
Add a code to properly test for presence of LLVMTestingSupport library
when performing a stand-alone build, and skip tests requiring it when
it is not present. Since the library is not installed, llvm-config
reported empty --libs for it and the tests failed to link with undefined
references. Skipping the two fdr_* test files is better than failing to
build, and should be good enough until we find a better solution.
NB: both installing LLVMTestingSupport and building it automatically
from within compiler-rt sources are non-trivial. The former due to
dependency on gtest, the latter due to tight integration with LLVM
source tree.
Differential Revision: https://reviews.llvm.org/D55891
llvm-svn: 349899
Copy the fix for determining the correct terminfo library from LLVM --
use distinct variables for check_library_exists() calls. Otherwise,
the first check (for -ltinfo) populates the variable and no other checks
are performed. Effectively, systems with other libraries than the first
one listed are presumed not to have terminfo routines at all.
Also sync the check order to include the NetBSD fix from r347156.
This partially fixes undefined symbols when linking XRay tests. It's
probably not the best solution to the problem there but as long
as the terminfo check stays in config-ix, I thnk it's worth fixing.
Differential Revision: https://reviews.llvm.org/D54641
llvm-svn: 347338
When building for default target only, use exact target spelling
when deriving the name for the per-target runtime directory. This
is necessary for AArch32 where the CMake build by default rewrites
the architecture which leads to unexpected results.
Differential Revision: https://reviews.llvm.org/D54612
llvm-svn: 347022
This is needed when cross-compiling for a different target since
CFLAGS may contain additional flags like -resource-dir which
change the location in which compiler-rt builtins are found.
Differential Revision: https://reviews.llvm.org/D54371
llvm-svn: 346820
When building the custom libc++ that's used by libFuzzer as well as
MSan and TSan tests, passthrough the C and C++ flags that were passed
to the compiler-rt CMake build. These may be needed to successfuly
compile the library on a particular platform.
Differential Revision: https://reviews.llvm.org/D53862
llvm-svn: 345788
When -ffreestanding is used, main() isn't considered special and
when compiled as C++ code it'll get mangled which makes the
compilation fail since main() will be undefined so this check will
never succeed.
Differential Revision: https://reviews.llvm.org/D49332
llvm-svn: 345632
Summary:
C++ flags should not be used for not-C++ files as it may trigger
-Werror=unused-command-line-argument. CMake will use CMAKE_C_FLAGS,
CMAKE_CXX_FLAGS, and CMAKE_ASM_FLAGS as appropriate implicitly, so
this does not need to be explicitly handled here.
This change depends on https://reviews.llvm.org/D53301, since one of
the builders depended on this behavior because it was not configuring
CMAKE_ASM_FLAGS.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis, vitalybuka
Subscribers: dberris, mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D53335
llvm-svn: 344751
Data involving struct accesses accounting work (plan to support only efficiency-cache-frag flag in the frontend side).
Reviewers: krytarowski, vitalybuka, jfb
Reviewed By : vitalybuka
Differential Revision: https://reviews.llvm.org/D52608
llvm-svn: 343812
The `--target` option is rejected by GCC starting from version 7.0.
It's shorter and more portable to use `mabi` option to select MIPS ABI
for testing target architecture. Clang supports that starting from r343169.
llvm-svn: 343182
Summary:
This change spans both LLVM and compiler-rt, where we do the following:
- Add XRay to the LLVMBuild system, to allow for distributing the XRay
trace loading library along with the LLVM distributions.
- Use `llvm-config` better in the compiler-rt XRay implementation, to
depend on the potentially already-distributed LLVM XRay library.
While this is tested with the standalone compiler-rt build, it does
require that the LLVMXRay library (and LLVMSupport as well) are
available during the build. In case the static libraries are available,
the unit tests will build and work fine. We're still having issues with
attempting to use a shared library version of the LLVMXRay library since
the shared library might not be accessible from the standard shared
library lookup paths.
The larger change here is the inclusion of the LLVMXRay library in the
distribution, which allows for building tools around the XRay traces and
profiles that the XRay runtime already generates.
Reviewers: echristo, beanz
Subscribers: mgorny, hiraditya, mboerger, llvm-commits
Differential Revision: https://reviews.llvm.org/D52349
llvm-svn: 342859
Summary:
This change introduces an `FDRLogWriter` type which is responsible for
serialising metadata and function records to character buffers. This is
the first step in a refactoring of the implementation of the FDR runtime
to allow for more granular testing of the individual components of the
implementation.
The main contribution of this change is a means of hiding the details of
how specific records are written to a buffer, and for managing the
extents of these buffers. We make use of C++ features (templates and
some metaprogramming) to reduce repetition in the act of writing out
specific kinds of records to the buffer.
In this process, we make a number of changes across both LLVM and
compiler-rt to allow us to use the `Trace` abstraction defined in the
LLVM project in the testing of the runtime implementation. This gives us
a closer end-to-end test which version-locks the runtime implementation
with the loading implementation in LLVM.
We also allow using gmock in compiler-rt unit tests, by adding the
requisite definitions in the `AddCompilerRT.cmake` module. We also add
the terminfo library detection along with inclusion of the appropriate
compiler flags for header include lookup.
Finally, we've gone ahead and updated the FDR logging implementation to
use the FDRLogWriter for the lowest-level record-writing details.
Following patches will isolate the state machine transitions which
manage the set-up and tear-down of the buffers we're using in multiple
threads.
Reviewers: mboerger, eizan
Subscribers: mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52220
llvm-svn: 342617
Instead of assuming `-ltinfo` works, check whether there's terminfo
support on the host where LLVMSupport is compiled.
Follow-up to D52220.
llvm-svn: 342523
Summary:
This change introduces an `FDRLogWriter` type which is responsible for
serialising metadata and function records to character buffers. This is
the first step in a refactoring of the implementation of the FDR runtime
to allow for more granular testing of the individual components of the
implementation.
The main contribution of this change is a means of hiding the details of
how specific records are written to a buffer, and for managing the
extents of these buffers. We make use of C++ features (templates and
some metaprogramming) to reduce repetition in the act of writing out
specific kinds of records to the buffer.
In this process, we make a number of changes across both LLVM and
compiler-rt to allow us to use the `Trace` abstraction defined in the
LLVM project in the testing of the runtime implementation. This gives us
a closer end-to-end test which version-locks the runtime implementation
with the loading implementation in LLVM.
We also allow using gmock in compiler-rt unit tests, by adding the
requisite definitions in the `AddCompilerRT.cmake` module.
Finally, we've gone ahead and updated the FDR logging implementation to
use the FDRLogWriter for the lowest-level record-writing details.
Following patches will isolate the state machine transitions which
manage the set-up and tear-down of the buffers we're using in multiple
threads.
Reviewers: mboerger, eizan
Subscribers: mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52220
llvm-svn: 342518
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 341082
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340949
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340860
compiler-rt CMake build currently tries to parse the triple and then
put it back together, but doing so inherently tricky, and doing so
from CMake is just crazy and currently doesn't handle triples that
have more than three components. Fortunatelly, the CMake really only
needs the architecture part, which is typically the first component,
to construct variants for other architectures. This means we can keep
the rest of the triple as is and avoid the parsing altogether.
Differential Revision: https://reviews.llvm.org/D50548
llvm-svn: 339701
Previously the the `weak_symbols.txt` files could be modified and the
build system wouldn't update the link flags automatically. Instead the
developer had to know to reconfigure CMake manually.
This is now fixed by telling CMake that the file being used to
read weak symbols from is a configure-time dependency.
Differential Revision: https://reviews.llvm.org/D50059
llvm-svn: 339559
This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.
Differential Revision: https://reviews.llvm.org/D47208
llvm-svn: 337881
This changes the name and the type to what it was prior to r333037
which matches the name of the flag used in other runtimes: libc++,
libc++abi and libunwind. We don't need the type to be a string since
there's only binary choice between libgcc and compiler-rt unlike in
the case of C++ library where there're multiple options.
Differential Revision: https://reviews.llvm.org/D49325
llvm-svn: 337116
when building with an IDE so that header files show up in the UI.
This massively improves the development workflow in IDEs.
To implement this a new function `compiler_rt_process_sources(...)` has
been added that adds header files to the list of sources when the
generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no
changes are made to the list of source files.
The function can be passed a list of headers via the
`ADDITIONAL_HEADERS` argument. For each runtime library a list of
explicit header files has been added and passed via
`ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of
headers was already present but it was stale and has been updated
to reflect the current state of the source tree.
The original version of this patch used file globbing (`*.{h,inc,def}`)
to find the headers but the approach was changed due to this being a
CMake anti-pattern (if the list of headers changes CMake won't
automatically re-generate if globbing is used).
The LLVM repo contains a similar function named `llvm_process_sources()`
but we don't use it here for several reasons:
* It depends on the `LLVM_ENABLE_OPTION` cache variable which is
not set in standalone compiler-rt builds.
* We would have to `include(LLVMProcessSources)` which I'd like to
avoid because it would include a bunch of stuff we don't need.
Differential Revision: https://reviews.llvm.org/D48422
llvm-svn: 336663
Summary:
In conjunction with the clang side change D48833, this will enable Scudo on
PPC64. I tested `check-scudo` on a powerpc64le box and everything passes.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48834
llvm-svn: 336213
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
build with an IDE (e.g. Xcode) as the generator.
Previously the global `USE_FOLDERS` property wasn't set in standalone
builds leading to existing settings of FOLDER not being respected.
In addition to this there were several targets that appeared at the top
level that were not interesting and clustered up the view. These have
been changed to be displayed in "Compiler-RT Misc".
Now when an Xcode project is generated from a standalone compiler-rt
build the project navigator is much less cluttered. The interesting
libraries should appear in "Compiler-RT Libraries" in the IDE.
Differential Revision: https://reviews.llvm.org/D48378
llvm-svn: 335728
OpenBSD needs lld linker for sanitisers.
Disabling lint checking as some symbols cannot be defined and block the proper unit tests launch.
Reviewers: lebedev.ri, vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48528
llvm-svn: 335524
This reverts commit r332924 and followup r332936 silencing a warning.
The change breaks the build on x86 if there is no 32-bit version of the
C++ libraries, see discussion in https://reviews.llvm.org/D47169.
llvm-svn: 334903
Respect a custom linker path provided by the user if one is present
(otherwise CMAKE_LINKER will have been set to the right value by CMake).
llvm-svn: 334654
When XRay is being built as part of the just built compiler together
with libc++ as part of the runtimes build, we need an explicit
dependency from XRay to libc++ to make sure that the library is
available by the time we start building XRay.
Differential Revision: https://reviews.llvm.org/D48113
llvm-svn: 334575
When building the dylib, the C++ headers are fundamentally non-module.
They require special versions of the headers in order to provide C++03 and
legacy ABI definitions. This causes ODR issues when modules are enabled
during both the build and the usage of the libc++ headers.
This patch fixes the build error by disabling modules when building the
libc++ sources.
llvm-svn: 334220
-z,defs is incompatible with sanitizers so we need to filter it out
from the linker flags before passing them to the libc++ build.
Differential Revision: https://reviews.llvm.org/D47865
llvm-svn: 334212
NFC now when libFuzzer supports only one architecture,
will stop being NFC after multiple architectures are supported.
Differential Revision: https://reviews.llvm.org/D47283
llvm-svn: 333239
Summary:
rL325492 disables FPU features when using soft floating point
(-mfloat-abi=soft), which is used internally when building for armv7. This
causes errors with builtins that utililize VFP instructions. With this change
we first check if VFP is enabled (by checking if the preprocessor macro
__VFP_FP__ is defined) before including such builtins.
Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith
Reviewed By: peter.smith
Subscribers: peter.smith, mgorny, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D47217
llvm-svn: 333216
Use compiler-rt builtins when selected as default Clang rtlib and avoid
explicitly passing -rtlib= flag to avoid the "argument unused during
compilation" warning.
This is a partial alternative to D47094 that does not rely on compiler
runtime checks.
Differential Revision: https://reviews.llvm.org/D47115
llvm-svn: 333037
Use libc++ when selected as default Clang stdlib and avoid checking
C++ compiler when using the in-tree version of libc++.
This is a partial alternative to D47094 that does not rely on compiler
runtime checks.
Differential Revision: https://reviews.llvm.org/D47100
llvm-svn: 333010
When using system C++ library, assume we have a working C++ compiler and
try to compile a complete C++ program. When using in tree C++ library,
only check the C compiler since the C++ library likely won't have been
built yet at time of running the check.
Differential Revision: https://reviews.llvm.org/D47169
llvm-svn: 332924
Rather then requiring the user to specify runtime the compiler
runtime and C++ standard library, or trying to guess them which is
error-prone, use auto-detection by parsing the compiler link output.
Differential Revision: https://reviews.llvm.org/D46857
llvm-svn: 332683
The source being compiled is plain C, but using .cc extension forces it
to be compiled as C++ which requires a working C++ compiler including
C++ library which may not be the case when we're building compiler-rt
together with libcxx as part of runtimes build.
Differential Revision: https://reviews.llvm.org/D47031
llvm-svn: 332679
The source being compiled is plain C, but using .cc extension forces it
to be compiled as C++ which requires a working C++ compiler including
C++ library which may not be the case when we're building compiler-rt
together with libcxx as part of runtimes build.
Differential Revision: https://reviews.llvm.org/D46152
llvm-svn: 331003
The Android sanitizer buildbot is failing with this change and it
looks like an additional change to cmake is necessary to fix the
build. Reverting this change for now.
llvm-svn: 329828
CMAKE_CXX_FLAGS was added twice to the command line. This causes the command
line options to be doubled which works until it doesn't as not all options
can be specified twice.
For example,
clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1
clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times!
llvm-svn: 329817
Summary:
- Enabling libfuzzer on OpenBSD
- OpenBSD can t support asan, msan ... the tests can t be run.
Patch by David CARLIER
Reviewers: eugenis, phosek, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44877
llvm-svn: 329631
Summary:
This is D45125; the patch enables the build of XRay on OpenBSD. We also
introduce some OpenBSD specific changes to the runtime implementation,
involving how we get the TSC rate through the syscall interface specific
to OpenBSD.
Reviewers: dberris
Authored by: devnexen
Subscribers: dberris, mgorny, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D45125
llvm-svn: 329189
Summary:
Porting HWASan to Linux x86-64, first of the three patches, compiler-rt part.
The approach is similar to ARM case, trap signal is used to communicate
memory tag check failure. int3 instruction is used to generate a signal,
access parameters are stored in nop [eax + offset] instruction immediately
following the int3 one
Had to add HWASan init on malloc because, due to much less interceptors
defined (most other sanitizers intercept much more and get initalized
via one of those interceptors or don't care about malloc), HWASan was not
initialized yet when libstdc++ was trying to allocate memory for its own
fixed-size heap, which led to CHECK-fail in AllocateFromLocalPool.
Also added the CHECK() failure handler with more detailed message and
stack reporting.
Reviewers: eugenis
Subscribers: kubamracek, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44705
llvm-svn: 328385
This changes the add_custom_libcxx macro to resemble the
llvm_ExternalProject_Add. The primary motivation is to avoid
unnecessary libFuzzer rebuilds that are being done on every
Ninja/Make invocation. The libc++ should be only rebuilt whenever
the libc++ source itself changes.
Differential Revision: https://reviews.llvm.org/D43213
llvm-svn: 326921
Summary:
On OpenBSD no multi arch support
Enabling only UBsan and disabling Asan.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44017
llvm-svn: 326646
Summary:
Enabling the memory sanitizer support for FreeBSD, most of unit tests are compatible.
- Adding fstat and stressor_r interceptors.
- Updating the struct link_map access since most likely the struct Obj_Entry had been updated since.
- Disabling few unit tests until further work is needed (or we can assume it can work in real world code).
Patch by: David CARLIER
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Subscribers: eugenis, dim, srhines, emaste, kubamracek, mgorny, fedor.sergeev, hintonda, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43080
llvm-svn: 326644
Summary:
- Enabling the build.
- Using assembly for the cpuid parts.
- Using thr_self FreeBSD call to get the thread id
Patch by: David CARLIER
Reviewers: dberris, rnk, krytarowski
Reviewed By: dberris, krytarowski
Subscribers: emaste, stevecheckoway, nglevin, srhines, kubamracek, dberris, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43278
llvm-svn: 325240
This change updates the Fuchsia-specific code to use the C++ friendly
duration expressions and flips on the building of
libclang_rt.fuzzer-x86_64.a and similar for Fuchsia. Given that
compiler-rt doesn't build on Fuchsia, test have been run by explicitly
building the library and linking it against
lib/fuzzer/tests/FuzzerUnittest.cpp.
Differential Revision: https://reviews.llvm.org/D42670
llvm-svn: 323828
Rainer Orth