Summary:
This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake.
This patch contains the following specific changes:
* Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake
* Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake
* Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration
I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64.
This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653.
Reviewers: samsonov, iains, jroelofs
Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D19742
llvm-svn: 268977
ASan interceptors contain local statics which run before the CRT is
initialized. Thread-safe statics appear to rely on CRT-internal state,
and will crash without this flag.
llvm-svn: 263979
Summary: Building the sanitizer libraries without rpaths causes all sorts of problems when you try to use them. This simple fix should make it all work.
Reviewers: samsonov, zaks.anna
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17556
llvm-svn: 261797
We already disabled various tests relying on C++ ABI knowledge, but we
still tried to build in this configuration on Windows which was a
mistake.
Fixes PR26415.
llvm-svn: 259388
* Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option
* On Darwin this results in calling dsymutil and strip after linking
* This generates an error on non-darwin platforms, matching the LLVM behavior
llvm-svn: 254643
There are situations where a user may want to build only the compiler-rt builtins, or only the sanitizer runtimes. This exposes options to do that. Both default to On, so there should be no implicit change in behavior.
llvm-svn: 247607
Instead, assume we're going to target triple specified by
COMPILER_RT_DEFAULT_TARGET_TRIPLE and build runtimes for this triple
(and hope that the host compiler can target them).
This will help users that use cross-compiler on their host to build
Clang that would work on a different architecture. This will also come in
handy if one would want to configure several compiler-rt build trees on
the same host, using just-built Clang that can target many
architectures.
This doesn't change the behavior in the default build configuration.
llvm-svn: 247099
Summary:
This is a reunification of three separate reviews D11073, D11082, D11083.
Having them separate was not constructive even though the patches were smaller because it led to fragmented conversations, and this is really all about one change.
This patch incorporates feedback from samsonov, and refactors the hacky darwin code out of the root CMakeLists.txt and int config-ix.cmake.
Reviewers: zaks.anna, bogner, kubabrecka, chandlerc, samsonov
Subscribers: jevinskie, filcab, llvm-commits
Differential Revision: http://reviews.llvm.org/D11820
llvm-svn: 244948
We will use this for ASan on Windows soon. When the ELF port of LLD
matures, we can add other sanitizer integration tests to make sure they
work with LLD.
llvm-svn: 244549
This applies default compiler flags to .S files, in particular removing
the "-pedantic" option, which is desirable because there is nothing to
reasonably warn about; and the only thing that gcc warns about is that
you allegedly can't correctly invoke GLUE2 in lib/builtins/assembly.h
on platforms for which USER_LABEL_PREFIX is the empty string.
In the gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305 that
added the warning, a commenter notes that giving a macro of zero characters
to another macro is not precisely the same as failing to supply an argument,
and "there is a widespread belief in C++ community that such usage is valid".
Unfortunately the only way to silence the warning is to avoid -pedantic.
Differential Revision: http://reviews.llvm.org/D10713
llvm-svn: 243446
Summary:
Although we assume that we can always target host triple, relax
this check to avoid failing at configure-time for cases when we are
not able to correctly infer/verify host triple for some reasons.
See http://llvm.org/bugs/show_bug.cgi?id=24222 for more details.
Reviewers: hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11496
llvm-svn: 243170
The is so that we can avoid using libgcc and use compiler-rt with
mingw-w64.
Related driver patch
http://reviews.llvm.org/D11077
I have tested this with mingw-w64 and everything seems to be in order.
I also sent this patch to the mingw-w64 mailing list for them to look at.
Patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11085
llvm-svn: 242539
Some users may need to configure Clang/compiler-rt with
-DMACOSX_DEPLOYMENT_TARGET=10.6, as they expect Clang to produce working
(non-sanitized) binaries on 10.6. In this case they would need to
additionally provide -DSANITIZER_MIN_OSX_VERSION=10.7 to mark
that sanitizer runtimes may only be used on 10.7+ (where they are
supported).
llvm-svn: 242363
Specifically:
- Start using %expect_crash.
- Provide an implementation of __ubsan::getDynamicTypeInfoFromVtable
for the Microsoft C++ ABI. This is all that is needed for CFI
diagnostics; UBSan's -fsanitize=vptr also requires an implementation of
__ubsan::checkDynamicType.
- Build the sanitizer runtimes against the release version of the C
runtime, even in debug builds.
- Accommodate demangling differences in tests.
Differential Revision: http://reviews.llvm.org/D11029
llvm-svn: 241745
Specifically:
- Disable int128 tests on Windows, as MSVC cl.exe does not support
int128, so we might not have been able to build the runtime
with int128 support.
- XFAIL the vptr tests as we lack Microsoft ABI support.
- XFAIL enum.cpp as UBSan fails to add the correct instrumentation code
for some reason.
- Modify certain tests that build executables multiple times to use
unique names for each executable. This works around a race condition
observed on Windows.
- Implement IsAccessibleMemoryRange for Windows to fix the last
misaligned.cpp test.
- Introduce a substitution for testing crashes on Windows using
KillTheDoctor.
Differential Revision: http://reviews.llvm.org/D10864
llvm-svn: 241303
-fsanitize=vptr is a UBSan feature that doesn't work on older Mac OS X
versions, and we don't want to penalize users that use modern OS with
default configuration. Those who want to target older OS versions, can
specify that versions explicitly.
llvm-svn: 240688
Summary:
This patch implements step 1 from
https://llvm.org/bugs/show_bug.cgi?id=23539#c10
I'd appreciate if you could test it on Mac OS and verify that parts of UBSan
runtime that reference C++ ABI symbols are properly excluded, and fix ASan/UBSan
builds.
Test Plan: regression test suite
Reviewers: thakis, hans
Subscribers: llvm-commits, zaks.anna, kubabrecka
Differential Revision: http://reviews.llvm.org/D10621
llvm-svn: 240617
Make sure that sanitizer runtimes target OS X version provided in
-mmacosx-version-min= flag. Enforce that it should be at least 10.7.
llvm-svn: 240356
This patch adds runtime support for the Safe Stack protection to compiler-rt
(see http://reviews.llvm.org/D6094 for the detailed description of the
Safe Stack).
This patch is our implementation of the safe stack on top of compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6096
llvm-svn: 239763
Summary:
This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library.
The goal of this is to try to push platform handling as low in the utility functions as possible.
Reviewers: rnk, samsonov
Reviewed By: rnk, samsonov
Subscribers: rnk, rsmith, llvm-commits
Differential Revision: http://reviews.llvm.org/D10250
llvm-svn: 239498
This reverts part of r237808.
The CMP0057 warnings came from an old development build of CMake that
nobody else has. We don't need the cruft.
llvm-svn: 237819
Fix a trivial instance of CMP0054 that came up on llvmdev.
The other warnings were CMP0057, which is about using the same file as a
MAIN_DEPENDENCY multiple times. The old behavior hasn't been a problem
yet, so I silenced the warning and filed PR23595 to document the issue
if someone cares.
llvm-svn: 237808
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
For OS X builds, both Make and CMake, let's be very explicit about using
libc++ and libc++abi with:
1) -stdlib=libc++ in CFLAGS and LDFLAGS for all platforms
2) -lc++ in LDFLAGS for all platforms
3) switch from -undefined dynamic_lookup to -lc++abi for UBSan in
Makefile-based builds
Reviewed at http://reviews.llvm.org/D8617
llvm-svn: 233215
Summary:
Switch to shared library for UBSan. Add support for building
UBSan on OSX and iossim by cargo-culting ASan build rules.
Test Plan: regression test suite
Reviewers: zaks.anna, kubabrecka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8473
llvm-svn: 233036
The SDK is insufficient to really build much. The builtins can be built
standalone now which is what the stub SDK was meant to permit. Remove the
unnecessary files.
llvm-svn: 230869
On OS X, if you don't have a full Xcode installation, but just the Command Line Tools package, xcrun and xcodebuild don't return a valid SDK root path. In these cases, let's use "/" as the SDK root (which is where the headers and libraries are installed).
Reviewed at http://reviews.llvm.org/D7641
llvm-svn: 230847
In both CMake and Makefiles, we are inconsistent about the use of libstdc++ vs. libc++, SDKs and minimum deployment targets for OS X. Let's fix the detection of SDKs, and let's explicitely set that we link against libc++ and mmacosx-version-min is 10.7.
llvm-svn: 227509
The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
Use unwind.h to get the declarations for unwinding interfaces. This header is
already provided by clang and gcc, so this adds no additional dependencies for
building the builtins library. It avoids the duplication which may drift over
time though.
llvm-svn: 225990
LLVM_LIBDIR_SUFFIX variable to one place in the cmake file.
This is all that I had to do to get everything from compiler-rt working
for me, but there may be more work required if folks are relying on more
parts of compiler-rt. Notably, I'm mostly using it for the sanitizers.
llvm-svn: 224928
Chris Bieneman