since we will be building both 32-bit and 64-bit compiler-rt builtins
from a single configuration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87113
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D87189
With runtimes-build, we lost map config for llvm-lit, so we can NOT run
lit from source dir anymore.
All the subdir target like: ninja check-llvm-codegen-powerpc will fail
too.
We will get some cfg error like:
File "../lvm-project/llvm/test/lit.cfg.py", line 21, in <module>
config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
AttributeError: 'NoneType' object has no attribute 'use_lit_shell'
This is reset of map config in llvm-lit rebuild.
We already have llvm-lit in runtimes-build, so don't build it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D87002
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86367
The `-fuse-ld=lld` check might succeed because there's a system lld,
but that lld may be out-of-date which would cause any tests that
attempt to use for LTO fail. This was observed on some of the bots.
Differential Revision: https://reviews.llvm.org/D81629
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
Summary:
The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`.
The comment about sanitizers and `-f[no-]function-sections` is corrected
also, as it is pertinent to this patch.
The sanitizer-related use of `-fno-function-sections` is associated with
powerpc64le, a target for which there is an IBM XL compiler, so that use
is updated in this patch to apply `-qnofuncsect` in case a build using
the XL compiler is viable on that platform.
This patch has been verified with the XL compiler on AIX only.
Reviewers: daltenty, stevewan
Reviewed By: daltenty
Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D72335
Summary:
This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
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
This fixes sanitizer-x86_64-linux-fuzzer which switched to new layout and not it
can't link as libcxx is always there.
We should support and tests libcxx but still it was unexpected that libfuzzer
ignored LLVM_ENABLE_PROJECTS_USED.
llvm-svn: 370153
Summary:
@eugenis to approve addition of //compiler-rt/tools.
@pree-jackie please confirm that this WFY.
D66494 introduced the GWP-ASan stack_trace_compressor_fuzzer. Building fuzz
targets in compiler-rt is a new affair, and has some challenges:
- If the host compiler doesn't have compiler-rt, the -fsanitize=fuzzer may not
be able to link against `libclang_rt.fuzzer*`.
- Things in compiler-rt generally aren't built when you want to build with
sanitizers using `-DLLVM_USE_SANITIZER`. This tricky to work around, so
we create the new tools directory so that we can build fuzz targets with
sanitizers. This has the added bonus of fixing the problem above as well, as
we can now just guard the fuzz target build to only be done with
`-DLLVM_USE_SANITIZE_COVERAGE=On`.
Reviewers: eugenis, pree-jackie
Reviewed By: eugenis, pree-jackie
Subscribers: dberris, mgorny, #sanitizers, llvm-commits, eugenis, pree-jackie, lebedev.ri, vitalybuka, morehouse
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D66776
llvm-svn: 370094
SystemZ builds show -Wframe-larger-than warnings in two functions:
'sanitizer::SuspendedThreadsListLinux::GetRegistersAndSP'
'sanitizer::SizeClassAllocator32<__sanitizer::AP32>::PopulateFreeList'
In both cases, the frame size looks correct; each of the functions has
a large local variable that brings the frame size close to the limit
even on x86, and the extra 160 bytes of the default register save areas
on SystemZ pushes it over the limit.
PowerPC and MIPS already disable this warning; do the same on SystemZ.
Differential Revision: https://reviews.llvm.org/D66021
llvm-svn: 369543
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
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
llvm-svn: 366447
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
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
- Fix cmake BOOL misspellings
- Set cmake policy for CMP0075 to NEW
As requested by smeenai I've compared CMAkeCache.txt in master with and
without this patch and the only changes are to the variable types I fixed:
$ diff build-b1-master/CMakeCache.txt build-b1-compiler-rt-fix-cmake-warnings/CMakeCache.txt
503c503
< COMPILER_RT_BAREMETAL_BUILD:STRING=OFF
---
> COMPILER_RT_BAREMETAL_BUILD:BOOL=OFF
550c550
< COMPILER_RT_HWASAN_WITH_INTERCEPTORS:STRING=ON
---
> COMPILER_RT_HWASAN_WITH_INTERCEPTORS:BOOL=ON
Patch by Wink Saville <wink@saville.com>.
Differential Revision: https://reviews.llvm.org/D61203
llvm-svn: 361866
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
Specify libdispatch header dir (include path) for lit tests. This is the
last missing piece in order to run the libdispatch tests on Linux even
when libdispatch is installed in a custom path instead of a default
(system) location.
llvm-svn: 357707
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 a new attempt for bringing TSan libdispatch support to Linux.
The main issue with the last patch (https://reviews.llvm.org/D53171) was
that we want to avoid building a separate library.
The updated plan is as follows:
1) Hide libdispatch support behind a flag: true on Darwin, false
elsewhere. If flag is specified, assume that libdispatch header and
-flbocks is available for building. This way we can directly include
the libdispatch header and rely on blocks runtime for our
implementation.
2) Optionally/weakly intercept libdispatch API functions.
This patch accomplishes 1). It compiles (without the flag enabled) on
Linux. Follow-up patches will provide 2) and enabling of tests on Linux.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D58935
llvm-svn: 355538
Building compiler-rt standalone outside of the main llvm
tree is supported, and in this case, the llvm cmake modules
are unavailable. (And even if they are available, it requires
including LLVMProcessSources.cmake, which currently isn't
included.)
This fixes building compiler-rt standalone with MSVC/clang-cl.
Differential Revision: https://reviews.llvm.org/D58767
llvm-svn: 355237
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
Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking
unit tests. This needs to be a full C++ library and cannot be libcxxabi.
Recommit r354132 which I reverted in r354153 because it broke a sanitizer
bot. This was because of the "fixes" for pthread linking, so I've removed
these changes.
Differential Revision: https://reviews.llvm.org/D58012
llvm-svn: 354198
Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking
unit tests. This needs to be a full C++ library and cannot be libcxxabi.
Differential Revision: https://reviews.llvm.org/D58012
llvm-svn: 354132
NDK r19 includes a sysroot that can be used directly by the compiler
without creating a standalone toolchain, so we just need a handful
of flags to point Clang there.
Differential Revision: https://reviews.llvm.org/D57733
llvm-svn: 353139
Rather than guessing whether to use static or shared version of
unwinder and c++abi when using linking against the in-tree versions,
provide a CMake option to control this.
Differential Revision: https://reviews.llvm.org/D57492
llvm-svn: 352723
Having libc++ checked out doesn't necessarily mean it should be built;
for example, the same source tree might be used for multiple build
configurations, and libc++ might not build in some of those
configurations. Add an option to compiler-rt's build to disable building
libc++. This defaults to ON, so it shouldn't change any existing build
configurations.
Differential Revision: https://reviews.llvm.org/D56479
llvm-svn: 351117
Summary:
This essentially reverts r337010 since it breaks UBSan, which is used
for a few platform libraries. The "-z global" flag is now added for
Scudo as well. The only other sanitizer shared libraries are for asan
and hwasan, which have also been reinstated to use the global flag.
Reviewers: cryptoad, eugenis
Reviewed By: cryptoad
Subscribers: kubamracek, mgorny, delcypher, #sanitizers, nickdesaulniers, chh, kongyi, pirama, llvm-commits
Differential Revision: https://reviews.llvm.org/D52770
llvm-svn: 343599
The CMAKE_<LANG>_ARCHIVE_FINISH rule doesn't need to be cleared for Darwin
static libraries. Avoid resetting the variables in the SIP case. If
CMAKE_RANLIB is cached, then CMake's Ninja generator will invoke ranlib during
installation, not due to the CMAKE_<LANG>_ARCHIVE_FINISH rule.
llvm-svn: 342511
David Tenty