Summary:
Since r223145 we don't include sanitizer_allocator_internal.h into
sanitizer_symbolizer.h, so we can have undefined reference to
Internal{Alloc, Free} stuff into sanitizer_symbolizer_libbacktrace.cc under
SANITIZER_CP_DEMANGLE macro.
This patch simply includes appropriate header into
sanitizer_symbolizer_libbacktrace.h to resolve the issue.
Patch by Maxim Ostapenko!
Reviewers: kcc, eugenis, samsonov
Subscribers: llvm-commits, ygribov
Differential Revision: http://reviews.llvm.org/D13429
llvm-svn: 249633
cl does not support the same intrinsics as clang. Provide implementations for
the intrinsics using MSVC builtins.
Patch by Tee Hao Wei!
llvm-svn: 249515
Unfortunately, int_utils.h needs to depend on int_lib for the common macro
definitions. However, currently, int_utils.h is included by int_lib.h. Reorder
the inclusion to work around this.
llvm-svn: 249376
Summary: This is the Makefile analog of r247833, except that the test also had to be changed such that clang actually attempts to link the program as opposed to just building it. Because of that change, I also switched the order to checking for ld/clang architecture support, because now lack of ld support would make the clang check fail. This fixes PR24776.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13425
llvm-svn: 249358
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
- Trim spaces.
- Use nullptr in place of 0 for pointer variables.
- Use '!p' in place of 'p == 0' for null pointer checks.
- Add blank lines to separate function definitions.
- Add 'extern "C"' or 'namespace foo' comments after the appropriate
closing brackets
This is a continuation of work from 409b7b82. The focus here is on the
various sanitizers (not sanitizer_common, as before).
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13225
llvm-svn: 248966
- Trim spaces.
- Use nullptr in place of 0 for pointer variables.
- Use '!p' in place of 'p == 0' for null pointer checks.
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13310
llvm-svn: 248964
We need to make sure that if you change the builtin filter lists CMake re-generates its configurations so it includes the right builtins in the generated libraries.
llvm-svn: 248852
Summary: This ports functionality from the clang_macho_embedded.mk platform makefile over to CMake.
Reviewers: bogner, samsonov, bob.wilson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13226
llvm-svn: 248850
We don't want to filter out the builtins that are present in libSystem like we do for the normal builtins because kexts can't link libSystem, but we should filter out all the builtins that are generally not supported on the OS and architecture.
llvm-svn: 248756
For Darwin simulator platforms we shouldn't build the cc_kext builtins at all because they aren't applicable, and we should includ the simulator builtins as slices inside the main platform builtin library.
llvm-svn: 248751
If the builtins are built with libgcc as the unwind provider on ARM, the exposed
_Unwind_SetIP is a macro. This results in the following warning due to
expansion of the argument:
warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
Add a no-op set of parenthesis around the argument that will prevent this
warning.
llvm-svn: 248686
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
Rename darwin_read_exclude_file to more generic darwin_read_list_from_file, and make it take the file path instead of constructing it so it can be reused more freely.
llvm-svn: 248635
OS and ARCH must be specified, but minimum version may not. Excluding the minimum version will only apply the filters for builtins not supported by the OS and OS-Arch pair.
llvm-svn: 248543
Summary: First pass at adding cc_kext_* builtin libraries. I need to cleanup and refactor the builtin filtering so that I can use it to filter the builtin symbols list, but this is the first step in the right direction.
Reviewers: bob.wilson, bogner, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13115
llvm-svn: 248443
Summary:
Xcode 7 doesn't support targeting iOS5 and earlier. Instead of just dropping cc_kext_ios5, I've repurposed it to cc_kext_ios, and I'm pulling the iOS architectures out of cc_kext. Putting OS X and iOS slices inside the same archive was just odd.
There is a cooresponding clang change coming too.
Reviewers: bogner, bob.wilson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13112
llvm-svn: 248441
There are lingering issues building the atomic builtins with various versions of gcc. To unblock people we can only include them on Apple platforms where they are more tested.
llvm-svn: 248386
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 fixes a crash in pthread_create on linux/i386 due to abi
incompatibility between intercepted and non-intercepted functions.
See the test case for more details.
llvm-svn: 248325
Currently aarch64 lacks instrumentation support for variadic arguments
for MSan. This patch sets the UBSan tests that uses it as to require
stable-runtime and sets aarch64/ubsan as an unstable one.
llvm-svn: 247996
error: width of bit-field 'allocated' (8 bits) exceeds the width of
its type; value will be truncated to 1 bit [-Werror,-Wbitfield-width]
llvm-svn: 247840
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
test/msan/dtor-trivial.cpp. Runtime testing for poisoning
vtable pointer in dtor.
Summary: Runtime testing for vtable ptr poisoning in dtor.
Reviewers: eugenis, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12713
Clean test case & comments.
Update tests for vptr poisoning order.
Simplify test to rely upon globals.
Assertions verify that vtable still accessible from dtors.
Testing linear inheritance and multiple inheritance for vtable poisoning.
Macros for testing expected failing functions.
Rename macros.
Removed xfail, modified FileCheck commands, to expect test to crash.
llvm-svn: 247763
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
If the pointer passed to the getVtablePrefix function was read from a freed
object, we may end up following pointers into objects on the heap and
printing bogus dynamic type names in diagnostics. However, we know that
vtable pointers will generally only point into memory mapped from object
files, not objects on the heap.
This change causes us to only follow pointers in a vtable if the vtable
and one of the virtual functions it points to appear to have appropriate
permissions (i.e. non-writable, and maybe executable), which will generally
exclude heap pointers.
Only enabled for Linux; this hasn't been tested on FreeBSD, and vtables are
writable on Mac (PR24782) so this won't work there.
Differential Revision: http://reviews.llvm.org/D12790
llvm-svn: 247484
This patch adds a runtime check for asan, dfsan, msan, and tsan for
architectures that support multiple VMA size (like aarch64). Currently
the check only prints a warning indicating which is the VMA built and
expected against the one detected at runtime.
llvm-svn: 247413
Evgeniy Stepanov