Summary:
This patch, on top of https://reviews.llvm.org/D40898, contains the build system
changes necessary to enable the Solaris/x86 sanitizer port.
The only issue of note is the libclang_rt.sancov_{begin, end} libraries: clang relies on the
linker automatically defining __start_SECNAME and __stop_SECNAME labels for
sections whose names are valid C identifiers. This is a GNU ld extension not present
in the ELF gABI, also implemented by gold and lld, but not by Solaris ld. To work around
this, I automatically link the sancov_{begin,end} libraries into every executable for now.
There seems to be now way to build individual startup objects like crtbegin.o/crtend.o,
so I've followed the lead of libclang_rt.asan-preinit which also contains just a single
object.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40899
llvm-svn: 321373
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320726
This change is the first in a series of changes to get the XRay runtime
building on macOS. This first allows us to build the minimal parts of
XRay to get us started on supporting macOS development. These include:
- CMake changes to allow targeting x86_64 initially.
- Allowing for building the initialisation routines without
`.preinit_array` support.
- Use __sanitizer::SleepForMillis() to work around the lack of
clock_nanosleep on macOS.
- Deprecate the xray_fdr_log_grace_period_us flag, and introduce
the xray_fdr_log_grace_period_ms flag instead, to use
milliseconds across platforms.
Reviewers: kubamracek
Subscribers: llvm-commits, krytarowski, nglevin, mgorny
Differential Review: https://reviews.llvm.org/D39114
llvm-svn: 319165
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
llvm-svn: 317875
Summary:
LSan is functional on PPC64 Linux now, let's enable all tests.
One test required ppc specific changes: use_registers.cc.
Reviewers: eugenis
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D39316
llvm-svn: 316698
Summary:
Enable check-cfi and check-ubsan on Android.
Check-ubsan includes standalone and ubsan+asan, but not tsan or msan.
Cross-dso cfi tests are disabled for now.
Reviewers: vitalybuka, pcc
Subscribers: srhines, kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38608
llvm-svn: 315105
Summary:
Mark Android as supported in the cmake configuration for Scudo.
Scudo is not added yet in the Android build bots, but code builds and tests
pass locally. It is for a later CL. I also checked that Scudo builds as part
of the Android toolchain.
A few modifications had to be made:
- Android defaults to `abort_on_error=1`, which doesn't work well with the
current tests. So change the default way to pass `SCUDO_OPTIONS` to the tests
to account for this, setting it to 0 by default;
- Disable the `valloc.cpp` & `random_shuffle.cpp` tests on Android;
- There is a bit of gymnatic to be done with the `SCUDO_TEST_TARGET_ARCH`
string, due to android using the `-android` suffix, and `i686` instead of
`i386`;
- Android doesn't need `-lrt`.
Reviewers: alekseyshl, eugenis
Reviewed By: alekseyshl
Subscribers: srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37907
llvm-svn: 313538
Summary:
This code already works and passes some number of tests.
There is need to finish remaining sanitizers to get better coverage.
Many tests fail due to overly long file names of executables (>31).
This is a current shortcoming of the NetBSD 8(beta) kernel, as
certain functions can fail (like retrieving file name of executable).
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, george.karpenkov
Reviewed By: kcc
Subscribers: mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37304
llvm-svn: 312183
Summary:
An implementation of ubsan runtime library suitable for use in production.
Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible
Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.
When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.
Reviewers: pcc, kcc
Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D36810
llvm-svn: 312029
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
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
Change the default of COMPILER_RT_SANITIZERS_TO_BUILD to "all" in
order to automatically pick up new sanitizers in existing build
trees.
llvm-svn: 311824
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
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, filcab, fjricci
Reviewed By: fjricci
Subscribers: srhines, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36483
llvm-svn: 310412
Summary:
Temporarily keep disabled COMPILER_RT_HAS_ASAN on NetBSD.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36312
llvm-svn: 310370
Android uses libgcc name even for shared library unlike other platforms
which use libgcc_s. Furthemore, Android libstdc++ has a dependency on
libdl. These need to be handled while performing CMake checks.
Differential Revision: https://reviews.llvm.org/D36035
llvm-svn: 309638
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 change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309060
Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.
Reviewers: kcc, kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29995
llvm-svn: 298946
Summary:
These sanitizers are enabled and used in Android but got built with
Android's build system. This change enables them in the CMake build
system.
Reviewers: eugenis
Subscribers: llvm-commits, danalbert, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D30127
llvm-svn: 295523
Summary:
Version 8 is the first version to support the __thread
keyword, which is required for building lsan for
64-bit ios.
Reviewers: kubamracek, kcc, glider
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29787
llvm-svn: 295412
Summary:
Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan
compilation and is turned off by default. Patches to fix build errors
when this flag is enabled will be uploaded soon.
This is part of an effort to port LSan to OS X, but LSan on OS X does not
currently work or pass tests currently.
Reviewers: kubamracek, kcc, glider, alekseyshl
Reviewed By: kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29783
llvm-svn: 295012
Revert "Fix -Wsign-compare - this might not be quite right, but preserves behavior"
Revert "[XRay] Implement powerpc64le xray."
This reverts commit r294826.
This reverts commit r294781.
llvm-svn: 294842
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
Summary:
Adding ARM64 as a supported architecture for Scudo.
The random shuffle is not yet supported for SizeClassAllocator32, which is used
by the AArch64 allocator, so disable the associated test for now.
Reviewers: kcc, alekseyshl, rengolin
Reviewed By: rengolin
Subscribers: aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28960
llvm-svn: 293068
Breaks tests on i686/Linux due to missing clang driver support:
error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu'
llvm-svn: 292844
People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403)
despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications
that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful.
This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list.
We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine
thus I'm posting it here to initiate further discussion.
Differential Revision: https://reviews.llvm.org/D28609
llvm-svn: 292775
Summary:
ARM & AArch64 runtime detection for hardware support of CRC32 has been added
via check of the AT_HWVAL auxiliary vector.
Following Michal's suggestions in D28417, the CRC32 code has been further
changed and looks better now. When compiled with full relro (which is strongly
suggested to benefit from additional hardening), the weak symbol for
computeHardwareCRC32 is read-only and the assembly generated is fairly clean
and straight forward. As suggested, an additional optimization is to skip
the runtime check if SSE 4.2 has been enabled globally, as opposed to only
for scudo_crc32.cpp.
scudo_crc32.h has no purpose anymore and was removed.
Reviewers: alekseyshl, kcc, rengolin, mgorny, phosek
Reviewed By: rengolin, mgorny
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D28574
llvm-svn: 292409
Summary:
As raised in D28304, enabling SSE 4.2 for the whole Scudo tree leads to the
emission of SSE 4.2 instructions everywhere, while the runtime checks only
applied to the CRC32 computing function.
This patch separates the CRC32 function taking advantage of the hardware into
its own file, and only enabled -msse4.2 for that file, if detected to be
supported by the compiler.
Another consequence of removing SSE4.2 globally is realizing that memcpy were
not being optimized, which turned out to be due to the -fno-builtin in
SANITIZER_COMMON_CFLAGS. So we now explicitely enable builtins for Scudo.
The resulting assembly looks good, with some CALLs are introduced instead of
the CRC32 code being inlined.
Reviewers: kcc, mgorny, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28417
llvm-svn: 291570
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
Disable the code appending -msse4.2 flag implicitly when the compiler
supports it. The compiler support for this flags do not indicate that
the underlying CPU will support SSE4.2, and passing it may result in
SSE4.2 code being emitted *implicitly*.
If the target platform supports SSE4.2 appropriately, the relevant bits
should be already enabled via -march= or equivalent. In this case
passing -msse4.2 is redundant.
If a runtime detection is desired (which seems to be a case with SCUDO),
then (as gcc manpage points out) the specific SSE4.2 needs to be
isolated into a separate file, the -msse4.2 flag can be forced only
for that file and the function defined in that file can only be called
when the CPU is determined to support SSE4.2.
This fixes SIGILL on SCUDO when it is compiled using gcc-5.4.
Differential Revision: https://reviews.llvm.org/D28304
llvm-svn: 291217
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
Summary:
With the previous modifications, the code works on ARM32. The random shuffle
test is unsupported on 32-bit platforms for the moment and being marked as
such. There is no hardware support for the checksum computation yet, this will
come at a later point.
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits, aemerson, rengolin, mgorny
Differential Revision: https://reviews.llvm.org/D27957
llvm-svn: 290201
This is used when building builtins for multiple targets as part
of LLVM runtimes.
Differential Revision: https://reviews.llvm.org/D26653
llvm-svn: 289489
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
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
Alex Shlyapnikov