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
Summary:
Use CMake's cmake_parse_arguments() instead.
It's called in a slightly different way, but supports all our use cases.
It's in CMake 2.8.8, which is our minimum supported version.
CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc):
http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments
Since I was already changing these calls, I changed ARCH and LIB into
ARCHS and LIBS to make it more clear that they're lists of arguments.
Reviewers: eugenis, samsonov, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10529
llvm-svn: 240120
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
Summary:
This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library.
The goal of this is to try to push platform handling as low in the utility functions as possible.
Reviewers: rnk, samsonov
Reviewed By: rnk, samsonov
Subscribers: rnk, rsmith, llvm-commits
Differential Revision: http://reviews.llvm.org/D10250
llvm-svn: 239498
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
Fix a trivial instance of CMP0054 that came up on llvmdev.
The other warnings were CMP0057, which is about using the same file as a
MAIN_DEPENDENCY multiple times. The old behavior hasn't been a problem
yet, so I silenced the warning and filed PR23595 to document the issue
if someone cares.
llvm-svn: 237808
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
Passing MSVC-style cflags to the gcc-style clang driver will almost
always end badly. Just translate a couple of simple flags used by the
base CMake cflags like /D, /U, and /O.
llvm-svn: 232219
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
When CMake builds a dynamic library on Windows, the .dll file's location is
determined by the RUNTIME_OUTPUT_DIRECTORY, which we were previously not
setting.
This means for example that clang_rt.asan_dynamic-i386.dll will get built
and installed in the same directory as the corresponding .lib file,
instead of being built in the bin/ directory and not installed at all.
Differential Revision: http://reviews.llvm.org/D6508
llvm-svn: 223387
Peter Collingbourne