Since we’re adding an entry into COMPILER_RT_SUPPORTED_ARCH for all architectures of all Darwin platforms, COMPILER_RT_SUPPORTED_ARCH often ends up having duplicate items. Let’s remove them.
Differential Revision: https://reviews.llvm.org/D25996
llvm-svn: 288681
Summary:
This update introduces i386 support for the Scudo Hardened Allocator, and
offers software alternatives for functions that used to require hardware
specific instruction sets. This should make porting to new architectures
easier.
Among the changes:
- The chunk header has been changed to accomodate the size limitations
encountered on 32-bit architectures. We now fit everything in 64-bit. This
was achieved by storing the amount of unused bytes in an allocation rather
than the size itself, as one can be deduced from the other with the help
of the GetActuallyAllocatedSize function. As it turns out, this header can
be used for both 64 and 32 bit, and as such we dropped the requirement for
the 128-bit compare and exchange instruction support (cmpxchg16b).
- Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2
instruction set is supported, use the 32-bit CRC32 instruction, and in the
XorShift128, use a 32-bit based state instead of 64-bit.
- Add software support for CRC32: if SSE 4.2 is not supported, fallback on a
software implementation.
- Modify tests that were not 32-bit compliant, and expand them to cover more
allocation and alignment sizes. The random shuffle test has been deactivated
for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't
currently randomize chunks.
Reviewers: alekseyshl, kcc
Subscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocache
Differential Revision: https://reviews.llvm.org/D26358
llvm-svn: 288255
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
It's not a good idea to build the sanitizers with e.g. -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12, because some deprecated functions that we intercept will cause build errors. Let's limit the allowed deployment targets to 10.9 (which is the default anyway), and warn when it's set above.
Differential Revision: https://reviews.llvm.org/D26557
llvm-svn: 286859
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
Currently, when doing a ASanified build of LLVM (with Clang, compiler-rt and libcxx) via -DLLVM_USE_SANITIZER=Address and not using any other options, we already disable building of sanitizer runtimes (because they themselves can’t be sanitized) and also exclude the sanitizer tests. However, the same is not done for the profiling runtime, which will build fine, but then all the tests fail due to linking errors. Let’s disable the profiling runtime as well (when LLVM_USE_SANITIZER is set).
Differential Revision: https://reviews.llvm.org/D24657
llvm-svn: 281815
Summary:
A few small changes required to permit building the sanitizers
with Clang instead of only with MSVC.
Reviewers: compnerd, beanz, rnk
Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D24092
llvm-svn: 280863
With this patch 10 out of 13 tests are passing.
Following is the list of failing tests:
struct-simple.cpp
workingset-signal-posix.cpp
mmap-shadow-conflict.c
Reviewed by bruening
Differential: D23799
llvm-svn: 280795
There was an invalid entry in the sanitizer list, remove it. This has no effect
on the building, just removes the definition of a cached variable.
llvm-svn: 280378
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
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
Summary:
This is a fixed-up version of D21612, to address failure identified post-commit.
Original commit description:
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).
Fixes include:
- Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built
- Including <cstddef> to fix std::size_t issue
Reviewers: kcc, rnk, echristo
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D22611
llvm-svn: 276251
and also the follow-up "[xray] Only build xray on Linux for now"
Two build errors were reported on the llvm-commits list:
[ 88%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_flags.cc.o
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/xray/xray_init.cc:23:10: fatal error: 'llvm/Support/ELF.h' file not found
#include "llvm/Support/ELF.h"
^
and
In file included from /w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface.cc:16:
/w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface_internal.h:36:8: error:
no type named 'size_t' in namespace 'std'
std::size_t Entries;
~~~~~^
llvm-svn: 276186
Summary:
A sysroot without c++ headers is able to build compiler-rt, don't
require them when configuring available architectures from cmake.
Reviewers: samsonov, beanz, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22469
llvm-svn: 276151
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
Kuba Mracek