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
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
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
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
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.
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:
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
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
Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards
the new features behind it.
This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66.
llvm-svn: 369527
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:
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
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
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
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
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
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
Logan Smith