Should fix the Windows buildbots, and maybe some other non-Linux Unix
bots too.
XRay currently depends on sanitizer_common, so associate it with the
"build sanitizers" option and remove the option for separately
controlling the XRay build.
llvm-svn: 276124
Summary:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Depends on D19904
Reviewers: echristo, kcc, rnk
Subscribers: rnk, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D21612
llvm-svn: 276117
Here's the warnings and how they were fixed:
- InstrProfilingUtil.c(110): warning C4013: '_open_osfhandle' undefined; assuming extern returning int
Include io.h to get the prototype.
- warning C4005: 'FILE_MAP_EXECUTE': macro redefinition
Stop trying to support pre-XP versions of Windows, don't attempt to
define this macro.
- InstrProfilingWriter.c(271): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Header'
- InstrProfilingWriter.c(275): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Zeroes'
Turn this warning off. This is definitely legal in C++, all compilers
accept it, and I only have room for half of one language standard in my
brain.
- InstrProfilingValue.c(320): warning C4113: 'uint32_t (__cdecl *)()' differs in parameter lists from 'uint32_t (__cdecl *)(void)'
Fix this with an explicit (void) in the prototype.
- InstrProfilingMerge.c.obj : warning LNK4006: _VPMergeHook already defined in InstrProfilingMergeFile.c.obj; second definition ignored
Last remaining warning. This is from linking a selectany definition with
a strong definition. We need to sort out weak symbols in compiler-rt in
general, though.
llvm-svn: 273026
- Fixes warnings about the ignored -fms-compatibility-version flag.
- Fixes warnings about overriding /W4 with /W3 and back.
- Fixes a warning where PREFETCH() expanded to nothing in a braceless if
block.
llvm-svn: 273021
Summary:
This is an initial implementation of a Hardened Allocator based on Sanitizer Common's CombinedAllocator.
It aims at mitigating heap based vulnerabilities by adding several features to the base allocator, while staying relatively fast.
The following were implemented:
- additional consistency checks on the allocation function parameters and on the heap chunks;
- use of checksum protected chunk header, to detect corruption;
- randomness to the allocator base;
- delayed freelist (quarantine), to mitigate use after free and overall determinism.
Additional mitigations are in the works.
Reviewers: eugenis, aizatsky, pcc, krasin, vitalybuka, glider, dvyukov, kcc
Subscribers: kubabrecka, filcab, llvm-commits
Differential Revision: http://reviews.llvm.org/D20084
llvm-svn: 271968
This macro is called from the base config, so it can't live in config-ix, it needs to be in the utils. I suspect the only reason this hasn't caused problems is that nobody is building the Android builtins from the builtins subdirectory.
llvm-svn: 271693
It's fixing compilation errors. The runtime is not yet working.
Missing features:
OverrideFunction for x64
an equiv function for inline asm (atomic_compare_exchange_strong)
shadow memory offset needs to be adjusted
RoundUpToInstrBoundary for x64
They will be implemented by subsequent patches.
Patch by Wei Wang.
Differential revision: http://reviews.llvm.org/D20455
llvm-svn: 271049
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
This change modifies find_darwin_sdk_dir to set a variable if a Darwin "Internal" SDK is present which allows CMake to disable components that require internal-only APIs.
This mechanism is then used to disable TSan when an internal SDK is not present.
llvm-svn: 267575
Summary:
Adds the initial version of a runtime library for the new
EfficiencySanitizer ("esan") family of tools. The library includes:
+ Slowpath code via callouts from the compiler instrumentation for
each memory access.
+ Registration of atexit() to call finalization code.
+ Runtime option flags controlled by the environment variable
ESAN_OPTIONS. The common sanitizer flags are supported such as
verbosity and log_path.
+ An initial simple test.
Still TODO: common code for libc interceptors and shadow memory mapping,
and tool-specific code for shadow state updating.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, vkalintiris, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19168
llvm-svn: 267060
sanitizer_common is now in good enough shape on s390x to support UBSan
- all tests passing. Let's enable it.
Differential Revision: http://reviews.llvm.org/D19157
llvm-svn: 266483
Update the compiler-rt cmake to build TSan dylibs for iOS-style simulators when the
corresponding COMPILER_RT_ENABLE_FOO_OS setting is enabled.
Differential Revision: http://reviews.llvm.org/D18277
Part of rdar://problem/24048382
llvm-svn: 263910
This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake.
This step will allow these macros to be re-used by the separated builtin build.
llvm-svn: 261108
This test requires llvm-symbolizer to be able to convert a stack
address into a function name. It is only able to do this if the
DIA SDK was found at cmake time. Add a lit feature for this,
and let the test depend on it.
See also discussion in D15363.
llvm-svn: 258545
Summary:
* Refactored the iOS config-ix.cmake code to be a more compact loop over supported embedded platforms.
* Added watchOS and tvOS as experimental platforms, they don't currently build so they are disabled by default
Reviewers: zaks.anna, kubabrecka, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16119
llvm-svn: 257544
Summary: This change configures Windows builds to build the complier-rt profile support library (clang_rt.profile-i386.lib). Windows API incompatibilities in the compiler-rt profile lib are also fixed.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15830
llvm-svn: 256848
This is an initial version of the runtime cross-DSO CFI support
library.
It contains a number of FIXMEs, ex. it does not support the
diagnostic mode nor dlopen/dlclose, but it works and can be tested.
Diagnostic mode, in particular, would require some refactoring (we'd
like to gather all CFI hooks in the UBSan library into one function
so that we could easier pass the diagnostic information down to
__cfi_check). It will be implemented later.
Once the diagnostic mode is in, I plan to create a second test
configuration to run all existing tests in both modes. For now, this
patch includes only a few new cross-DSO tests.
llvm-svn: 255695
This patch enables the safestack for aarch64. The frontend already have
it enabled on all supported architectures and no adjustment is required
in llvm.
The compiler-rt adjustments are basically add on the cmake configuration
to enable the tests and fix the pagesize debug check by getting its
value at runtime (since aarch64 has multiple pagesize depending of
kernel configuration).
llvm-svn: 255345
Summary:
Rather than having to add new "experimental" options each time someone wants to work on bringing a sanitizer to a new platform, this patch makes options for all of them.
The default values for the options are set by the platform checks that would have enabled them, but they can be overridden on or off.
Reviewers: kubabrecka, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14846
llvm-svn: 255170
msse3 is a target dependent flag and must be guarded as check_cxx_compiler_flag()
checks only for compiler error messages and ignores warnings. Earlier COMPILER_RT_HAS_MSSE3_FLAG
is set to "TRUE" for all targets as clang emits warnings and the compilation spits unnecessary
warnings for non-X86 targets. This issue is fixed by coupling the flag with "-Werror"
Differential Revision: http://reviews.llvm.org/D15362
llvm-svn: 255165
This patch is by Simone Atzeni with portions by Adhemerval Zanella.
This contains the LLVM patches to enable the thread sanitizer for
PPC64, both big- and little-endian. Two different virtual memory
sizes are supported: Old kernels use a 44-bit address space, while
newer kernels require a 46-bit address space.
There are two companion patches that will be added shortly. There is
a Clang patch to actually turn on the use of the thread sanitizer for
PPC64. There is also a patch that I wrote to provide interceptor
support for setjmp/longjmp on PPC64.
Patch discussion at reviews.llvm.org/D12841.
llvm-svn: 255057
Second attempt to enable building ThreadSanitizer (and running tests) on OS X by default.
Differential Revision: http://reviews.llvm.org/D15109
llvm-svn: 254603
Apparently check_c_compiler_flag isn't a thing everywhere. Not being
incredibly well-versed in cmake, I'm hoping that check_cxx_compiler_flag
serves a similar purpose. :)
llvm-svn: 253648
Hi, this patch adds a CMake flag called `COMPILER_RT_ENABLE_TSAN_OSX`, which is off by default. If enabled, the build system will be building the OS X version of the TSan runtime library (called `libclang_rt.tsan_osx_dynamic.dylib`). I'll submit patches that fix OS X build errors shortly.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
llvm-svn: 251915
This patch add support for leak sanitizer for aarch64. Similar to
MIPS it uses a SizeClassAllocator32 due VMA constraints (aarch64
currently supports 39 and 42-bit VMA).
It also fixes the android build issue.
llvm-svn: 250898
This patch add support for leak sanitizer for aarch64. Similar to
MIPS it uses a SizeClassAllocator32 due VMA constraints (aarch64
currently supports 39 and 42-bit VMA).
llvm-svn: 249337
This somehow worked with the build on Linux, but seems to fail on the buildbots.
Split the flags apart here as otherwise the two flags are treated as one, and
cause a compilation failure.
llvm-svn: 248654
This adds a new name for ARM32 (armhf). We now force that the default build for
ARM32 (arm) to be soft-float ABI. This has a corresponding clang change to look
for these names based on the floating point ABI. The functions are built
identically (the functions are marked as AAPCS, so the calling convention does
not change, as per the RTABI specification), however, the object file contains
attributes indicating the build configuration which the linker will ensure are
not mix and matched. We now built the appropriate named archive so that we can
link properly.
llvm-svn: 248648
Summary:
Building the builtins on Darwin platforms is a bit complicated. This is a first-pass implementation of the functionality from clang_darwin.mk into CMake.
When building the builtins on Darwin we have layers of blacklists that we apply based on platform, architecture, and minimum supported OS version.
Reviewers: bogner, filcab, bob.wilson, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13059
llvm-svn: 248383
This patch enabled msan for aarch64 with 39-bit VMA and 42-bit VMA.
As defined by lib/msan/msan.h the memory layout used is for 39-bit is:
00 0000 0000 - 40 0000 0000: invalid
40 0000 0000 - 43 0000 0000: shadow
43 0000 0000 - 46 0000 0000: origin
46 0000 0000 - 55 0000 0000: invalid
55 0000 0000 - 56 0000 0000: app (low)
56 0000 0000 - 70 0000 0000: invalid
70 0000 0000 - 80 0000 0000: app (high)
And for 42-bit VMA:
000 0000 0000 - 100 0000 0000: invalid
100 0000 0000 - 11b 0000 0000: shadow
11b 0000 0000 - 120 0000 0000: invalid
120 0000 0000 - 13b 0000 0000: origin
13b 0000 0000 - 2aa 0000 0000: invalid
2aa 0000 0000 - 2ab 0000 0000: app (low)
2ab 0000 0000 - 3f0 0000 0000: invalid
3f0 0000 0000 - 400 0000 0000: app (high)
Most of tests are passing with exception of:
* Linux/mallinfo.cc
* chained_origin_limits.cc
* dlerror.cc
* param_tls_limit.cc
* signal_stress_test.cc
* nonnull-arg.cpp
The 'Linux/mallinfo.cc' is due the fact AArch64 returns the sret in 'x8'
instead of default first argument 'x1'. So a function prototype that
aims to mimic (by using first argument as the return of function) won't
work. For GCC one can make a register alias (register var asm ("r8")), but
for clang it detects is an unused variable and generate wrong code.
The 'chained_origin_limits' is probably due a wrong code generation,
since it fails only when origin memory is used
(-fsanitize-memory-track-origins=2) and only in the returned code
(return buf[50]).
The 'signal_streess_test' and 'nonnull-arg' are due currently missing variadic
argument handling in memory sanitizer code instrumentation on LLVM side.
Both 'dlerror' and 'param_tls_test' are unknown failures that require
further investigation.
All the failures are XFAIL for aarch64 for now.
llvm-svn: 247809
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:
I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin.
The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again.
Reviewers: samsonov, chh, compnerd, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12500
llvm-svn: 246487
This patch adds support for tsan on aarch64-linux with 42-bit VMA
(current default config for 64K pagesize kernels). The support is
enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time
for both clang/llvm and compiler-rt. The default VMA is 39 bits.
It also enabled tsan for previous supported VMA (39).
llvm-svn: 246330
Summary:
There are a number of issues with unit tests on Darwin. These patches address the following:
* Unit tests should be passed -arch (-m32/-m64 isn't sufficient)
* Unit tests should be passed ${DARWIN_osx_CFLAGS} because they're being built for OS X
* Test architectures should be filtered based on base system capabilities (i.e. don't try running x86_64h tests on pre-haswell hardware).
Reviewers: bogner, filcab, kubabrecka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12174
llvm-svn: 245580
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
This patch enabled TSAN for aarch64 with 39-bit VMA layout. As defined by
tsan_platform.h the layout used is:
0000 4000 00 - 0200 0000 00: main binary
2000 0000 00 - 4000 0000 00: shadow memory
4000 0000 00 - 5000 0000 00: metainfo
5000 0000 00 - 6000 0000 00: -
6000 0000 00 - 6200 0000 00: traces
6200 0000 00 - 7d00 0000 00: -
7d00 0000 00 - 7e00 0000 00: heap
7e00 0000 00 - 7fff ffff ff: modules and main thread stack
Which gives it about 8GB for main binary, 4GB for heap and 8GB for
modules and main thread stack.
Most of tests are passing, with the exception of:
* ignore_lib0, ignore_lib1, ignore_lib3 due a kernel limitation for
no support to make mmap page non-executable.
* longjmp tests due missing specialized assembly routines.
These tests are xfail for now.
The only tsan issue still showing is:
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
Which still required further investigation. The test is disable for
aarch64 for now.
llvm-svn: 244055
This patch enables asan for aarch64/linux. It marks it as 'unstable-release',
since some tests are failing due either kernel missing support of non-executable
pages in mmap or environment instability (infinite loop in juno reference
boards).
It sets decorate_proc_maps test to require stable-release, since the test expects
the shadow memory to not be executable and the support for aarch64 is only
added recently by Linux (da141706aea52c1a9 - 4.0).
It also XFAIL static_tls test for aarch64 linker may omit the __tls_get_addr call
as a TLS optimization.
llvm-svn: 244054
This patch enable DFSan for AArch64 (39-bit VMA). All tests are passing
but:
* test/dfsan/custom.cc
Due an invalid access in dl_iterate_phdr instrumentation (commenting out
this function make the testcase to pass). The test is XFAIL for aarch64
for now.
llvm-svn: 243688
Clang will not define __i686__, even when the target triple is i686,
without -march=i686.
With this patch, the compiler-rt build will successfully detect that
Clang can target i686.
The open_memstream.cc test is a little funny. Before my patch, it
was invoked with "-m32 -m64". To make it work after my -march
change, I had to add '-march=x86-64'.
Differential Revision: http://reviews.llvm.org/D11618
llvm-svn: 243604
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
Summary:
This patch adds basic memory sanitizer support for PPC64. PR23219.
I have further patches ready to enable it in LLVM and Clang, and to fix
most of the many failing tests in check-msan.
Reviewers: kcc, willschm, samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: wschmidt, llvm-commits
Differential Revision: http://reviews.llvm.org/D10648
llvm-svn: 240623
This change makes cmake fail to even run on Darwin with errors
evaluating "$<TARGET_OBJECTS:RTInterception.x86_64>".
This reverts r239955
llvm-svn: 239985
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
lib/Target/AArch64/AArch64FrameLowering.cpp:370: virtual void llvm::AArch64FrameLowering::emitPrologue(llvm::MachineFunction&, llvm::MachineBasicBlock&) const: Assertion `!(NeedsRealignment && NumBytes==0) && "NumBytes should never be 0 when realignment is needed"' failed.
llvm-svn: 239352
This is done by creating a named shared memory region, unlinking it
and setting up a private (i.e. copy-on-write) mapping of that instead
of a regular anonymous mapping. I've experimented with regular
(sparse) files, but they can not be scaled to the size of MSan shadow
mapping, at least on Linux/X86_64 and ext3 fs.
Controlled by a common flag, decorate_proc_maps, disabled by default.
This patch has a few shortcomings:
* not all mappings are annotated, especially in TSan.
* our handling of memset() of shadow via mmap() puts small anonymous
mappings inside larger named mappings, which looks ugly and can, in
theory, hit the mapping number limit.
llvm-svn: 238621
Without the --target flag, clang uses the mips64 triple which selects the n64 abi. We need to add --target=mips-linux-gnu, so that clang can select the correct abi for mips32r2.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9249
llvm-svn: 237675
Summary:
This will allow us to enable it on the buildbot (and then enable a
sanitizer buildbot).
The problem is that gcc for Mips does not accept -m32/-m64 like clang does.
We therefore need to use the nearest equivalent -mips32r2/-mips64r2. We must
also specify -mabi=64 in the -mips64r2 case since gcc's default ABI has
traditionally been N32 whereas clang's is N64.
Reviewers: sagar
Reviewed By: sagar
Subscribers: llvm-commits, samsonov, kcc, mohit.bhakkad, Anand.Takale, sagar
Differential Revision: http://reviews.llvm.org/D8892
llvm-svn: 235299
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
One test case is updated to allow for differences between power and other architectures in behavior when returning from main in certain instances
http://reviews.llvm.org/D8743
llvm-svn: 233813
This reverts commit r229665. It seems that the AArch64 ASAN tests, that
pass on all our internal machines, doesn't like the public buildbot.
Turning this off until we can investigate the public bot for a better
understanding.
llvm-svn: 229739
Prior to this change we built two identical runtimes, named "powerpc64"
and "powerpc64le", while their actual endianness matched the host
endianness.
llvm-svn: 228650
This reverts commit r227966, which turned ASAN on on AArhc64 and may be the
cause of the bots never finishing the check-all. I'll re-apply once we're
sure that bot can cope with it.
llvm-svn: 228023
This commit changes the strategy for building shared ASan runtime
and the way we test it:
- COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now
always build shared ASan runtime (it is the default on Android,
Windows and Mac, and not the default on Linux and FreeBSD).
- Platforms, which use static runtime by default now have
"check-asan-dynamic" testsuite. This testsuite contains instrumented
unit tests, and ASan lit tests, and runs them with shared ASan
runtime. This testsuite is *not* a part of "check-asan" and
*not* a part of "check-all", as adding 1000 more test cases, which
duplicate existing ones is costly. However, you're welcome to
add this command to your buildbot.
llvm-svn: 224470
Summary:
I don't know anything about profiling but it seems to work out of the
box on PowerPC64. At least "make check-profile" works.
A few tests needed tweaking because PowerPC64 IR declares main with
"define signext i32 @main" instead of just "define i32 @main".
This also fixes the asan asan_and_llvm_coverage_test test, which
compiles with -coverage so requires that a profiling version of
libclang_rt has been built.
Reviewers: dexonsmith, kcc, samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D6233
llvm-svn: 221877
objects with the powerpc64le name. i.e. asan-powerpc64le.a
This change allows those objects to be built.
Differential Revision: http://reviews.llvm.org/D6043
llvm-svn: 221356
C4146: 'unary minus operator applied to unsigned type, result still unsigned'
C4291: ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception'
C4800: ''type' : forcing value to bool 'true' or 'false' (performance warning)'
llvm-svn: 220507
cmake/config-ix.cmake: Enabled building of asan for mipsel arch
test/asan/CMakeLists.txt: Enabled testing of asan for mipsel
Patch by Kumar Sukhani
Differential Revision: http://reviews.llvm.org/D5615
llvm-svn: 219496
Makes sure ARM bots don't run AArch64 and vice-versa, since not all
AArch64 systems can run AArch32 and no ARM hardware can run AArch64.
llvm-svn: 219304
Summary:
Changed cmake/config-ix.cmake to add support for different MIPS architectures: mips, mipsel, mips64, mips64el
In profile code there is no target based dependencies, so just enabling mips flag does the work.
Patch by Mohit Bhakkad
Reviewers: dsanders, void, petarj, kcc, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits, farazs, kumarsukhani
Differential Revision: http://reviews.llvm.org/D4880
llvm-svn: 218866
This is needed so we can produce -i686- named libraries for
x86 Android (which is i686-linux-android).
An alternative solution would be keeping the "i386" name internally and
tweaking the OUTPUT_NAME of compiler-rt libraries.
llvm-svn: 218761
* Detect Android toolchain target arch and set correct runtime library name.
* Merged a lot of Android and non-Android code paths.
* Android is only supported in standalone build of compiler-rt now.
* Linking lsan-common in ASan-Android (makes lsan annotations work).
* Relying on -fsanitize=address linker flag when building tests (again,
unification with non-Android path).
* Runtime library moved from lib/asan to lib/linux.
llvm-svn: 218605
Changed files:
config-ix.cmake: Enabled UBSan for MIPS32
sanitizer_stacktrace.cc: Program counter for MIPS32 is four byte aligned
and a delay slot so subtracted PC by 8 for getting call site address.
cast-overflow.cpp: Added big endian support for this test case.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D4881
llvm-svn: 218519
a given platform in a top-level CMakeLists.txt to use it both
in lib/ and in test/ subdirectories. Move architecture/platform
checks to config-ix.
llvm-svn: 215247
Reid Kleckner