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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
`set_target_compile_flags()` ultimately sets COMPILE_FLAGS which is
added to CMAKE_CXX_FLAGS in the compile rule, so passing
CMAKE_CXX_FLAGS causes them to be duplicated.
Differential Revision: https://reviews.llvm.org/D42398
llvm-svn: 323626
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42462
llvm-svn: 323606
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323054
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323032
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322451
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322256
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322234
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322153
This also slightly refactors the code that's checking the directory
presence which allows eliminating one unnecessary variable.
Differential Revision: https://reviews.llvm.org/D40637
llvm-svn: 320446
These targets strip during installation, and are required to support
install-distribution-stripped in LLVM (to support a stripped
distribution). LLVM has an add_llvm_install_targets function for this
purpose, but we can't rely on LLVM being present.
Differential Revision: https://reviews.llvm.org/D40687
llvm-svn: 319569
Now that we have disabled the run-forever tests, and cleaned up the
intel 80-bit float based tests, we should be able to enable testing
compiler-rt for powerpc64.
llvm-svn: 319474
This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target.
Differential Revision: https://reviews.llvm.org/D40143
llvm-svn: 319339
Multi-config CMake generators need lit to be able to resolve paths of
artifacts from previous build steps at lit time, rather than expect them
to be fully resolved at CMake time as they may contain the build mode.
Differential Revision: https://reviews.llvm.org/D38471
llvm-svn: 318037
Fix typo in variable assignment inside sanitizer_test_compile() that
resulted in TEST_DEPS parameter not being included in the clang_compile()
call. Spotted by George Karpenkov in D38444.
Differential Revision: https://reviews.llvm.org/D38838
llvm-svn: 315604
Summary:
Some architecture-specific function overrides (for example, i386/ashrdi3.S)
duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions
by filtering out the generic files before compiling.
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37166
llvm-svn: 312140
Summary:
Recent changes canonicalized clang_rt library names to refer to
"i386" on all x86 targets. Android historically uses i686.
This change adds a special case to keep i686 in all clang_rt
libraries when targeting Android.
Reviewers: hans, mgorny, beanz
Subscribers: srhines, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37278
llvm-svn: 312048
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311924
- Not having a dependency does not work in standalone build, as Clang does not exist.
- if (TARGET clang) check is useless, as it is order-dependent,
and Clang may not be registered yet.
Differential Revision: https://reviews.llvm.org/D37228
llvm-svn: 311911
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311842
The problem is that CMake is mostly imperative and the result of
processing "if (TARGET blah)" checks depends on the order of import of
CMake files.
In this case, "projects" folder is registered before "tools",
and calling "CheckClangHeaders" [renamed to have a better name]
errors out without even giving Clang a chance to be built.
This, in turn, leads to libFuzzer bot failures in some circumstances on
some machines (depends on whether LIT or UNIT tests are scheduled
first).
Differential Revision: https://reviews.llvm.org/D37126
llvm-svn: 311733
Resulting library binaries will be named libclang_rt.fuzzer*, and will
be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
CMake's add_custom_target is considered to be *always* out of date.
This patch changes it to a combination of add_custom_target and
add_custom_command which actually tracks dependencies' timestamps.
On my machine this reliably saves 6-7 seconds on each test group.
This can be a large difference when debugging small tests.
Differential Revision: https://reviews.llvm.org/D36912
llvm-svn: 311384
into a function.
Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:
For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.
Differential Revision: https://reviews.llvm.org/D36116
llvm-svn: 310971
Detect ObjC files in `clang_compile` and pass an appropriate flag to a
compiler, also change `clang_compile` to a function.
Differential Revision: https://reviews.llvm.org/D36727
llvm-svn: 310945
Change macro to a function, and use a generic variable instead of
branching for handling multi-output build with
CMAKE_CONFIGURATION_TYPES.
Differential Revision: https://reviews.llvm.org/D36725
llvm-svn: 310944
Change macro to a function, move creating test directory into
`add_compiler_rt_test`.
Differential Revision: https://reviews.llvm.org/D36724
llvm-svn: 310943
Currently there's a large amount of CMake logic duplication for
compiling sanitizer tests.
If we add more sanitizers, the duplication will get even worse.
This change factors out common compilation commands into a macro
available to all sanitizers.
llvm-svn: 309405
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309361
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309341
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309306
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309060
This improves find_darwin_sdk_dir to cache the results of executing xcodebuild to find the SDK. Should significantly reduce the CMake re-configure time.
Differential Revision: https://reviews.llvm.org/D34736
llvm-svn: 307344
Adds a CMake option DARWIN_PREFER_PUBLIC_SDK, off by default. When on, this prefers to use the public SDK, even when an internal one is present. With this, it's easy to emulate a build that the public buildbots are doing.
Differential Revision: https://reviews.llvm.org/D35071
llvm-svn: 307330
This patch adds a basic support for running the ASan lit test suite against an iOS Simulator. This is done by generating more lit.site.cfg configurations into subdirectories such as IOSSimI386Config and IOSSimX86_64Config. These test suites are not added into "check-all" or into "check-asan", they have to be run manually.
Differential Revision: https://reviews.llvm.org/D31477
llvm-svn: 301443
Summary: Currently, we build the compiler-rt runtimes with link-time optimization if LTO is configured for the LLVM project. This will break external programs that don't invoke the linker in such a way that it supports LLVM's LTO. To avoid this, this change causes the compiler-rt runtimes to be compiled with -fno-lto. This also makes the check-profile tests work on systems when doing a lld LTO build on a system where the system linker does not support LLVM LTO.
Reviewers: rnk, davidxl
Reviewed By: davidxl
Subscribers: dberris, mgorny, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D31218
llvm-svn: 298525
Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed.
Reviewers: davidxl, beanz
Reviewed By: beanz
Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D31098
llvm-svn: 298413
Summary:
Hi Michal,
Would you be able to review this simple fix, please?
Since r291504 compiler-rt uses `llvm-config --cmakedir` to get the path to the LLVM CMake modules.
On Windows this option returns Windows style path with backslashes. CMake treats backslashes as beginning of an escaped character and thus fails to append the path to `CMAKE_MODULE_PATH`.
Reviewers: compnerd, mgorny
Reviewed By: mgorny
Subscribers: compnerd, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D28908
llvm-svn: 293195
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.
llvm-svn: 291504
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
a warning that 'gtest-all.cc' directly triggers in the newer 1.8.0
version.
This should fix a warning in folks' build and bring a couple of -Werror
bots back to life.
llvm-svn: 291070
This is used when building builtins for multiple targets as part
of LLVM runtimes.
Differential Revision: https://reviews.llvm.org/D26653
llvm-svn: 289489
This was changed in rL276151 and causes problems if the C++ compiler does not
support the same arches as the C compiler.
For the builtins, only the C compiler is tested in try_compile_only.
Additionally, -fno-exceptions is passed in (if available) to work around
the case where no libunwind is available.
Differential Revision: https://reviews.llvm.org/D23654
llvm-svn: 282054
Summary:
Much of the non-Darwin build system assumes that COMPILER_RT_DEFAULT_TARGET_TRIPLE is the default target triple for the compiler being used. With clang as your compiler this isn't necessarily true.
To ensure that the rest of the build system behaves as expected this patch adds "--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE}" to the compiler flags for C, CXX and ASM sources.
Reviewers: compnerd, rengolin, fjricci
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24156
llvm-svn: 282024
Support overriding LLVM_* variables obtained from llvm-config when doing
stand-alone builds. The override of LLVM_MAIN_SRC_DIR is necessary to
provide LLVM sources when the initial directory used to build LLVM does
no longer exist when compiler-rt is built stand-alone. This is
especially the case when building the projects separately in temporary
directories with unpredictable names.
The code is based on existing CMakeLists.txt from clang. Alike clang, it
extends the override to all queried variables.
Differential Revision: https://reviews.llvm.org/D24005
llvm-svn: 281461
Summary:
Make sure that windows libraries contain the suffixes expected by clang.
This is expecially important when compiling the windows builtins with
clang, as cmake will use .a as the suffix by default.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D24046
llvm-svn: 280854
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
Summary:
Since we generate the compiler invocation on our own, we need to
manually add -target if CMAKE_C_COMPILER_TARGET has been specified.
Reviewers: compnerd, beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23823
llvm-svn: 279747
This should resolve PR23162. This patch has two parts.
First we need to check the error code from xcodebuild when querying for SDKs, second if the OS X SDK is not discovered, we ensure that /usr/include exists and use / as the OS X sysroot.
llvm-svn: 279336
This is a wrapper target of all the component install targets. This wrapper target will be used by the new LLVM runtimes directory to connect top-level targets to the runtime project target.
llvm-svn: 279333
Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes
either a special token `all` (default) which will preserve the current behaviour
or a CMake list of sanitizers to build. It will still perform the normal checks
if the sanitizer is requested. It only permits a further means to exclude a
particular sanitizer. This gives finer grained control than
`COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control.
llvm-svn: 279253
This fixes a long-standing TODO by implementing a compiler check for supporting the _Atomic keyword. If the _Atomic keyword is supported by the compiler we should include it in the builtin library sources.
llvm-svn: 278454
Summary: rnk reported that MSVC ignores unknown flags and still returns 0. This should cause unknown flags to be an error during the compiler check.
Reviewers: rnk
Subscribers: brad.king, llvm-commits
Differential Revision: https://reviews.llvm.org/D23030
llvm-svn: 277377
Allowing this variable to be cached makes it possible to repair the MIPS
buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the
detection of mips64 support (which I think was changed by r268977 but didn't
take effect on this buildbot until the last couple days) so that it returns to
not being built on these buildbots.
llvm-svn: 276402
Summary:
Use stricter comparisons for architecture. This prevents cmake from failing
for sysroots which can only compile armhf and not arm, since
arm MATCHES armhf is true, while arm STREQUAL armhf is false.
Reviewers: beanz, compnerd
Subscribers: aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D22473
llvm-svn: 276148
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Summary:
The MSVC compiler is complaining about invalid flags. The CFLAGS are passed
to the linker (i.e. /Gy-, ...).
Reviewers: rnk
Subscribers: llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21554
llvm-svn: 273265
Petr Hosek