Summary:
This removes the hard limit on the number of loaded modules (used to be
16K), and makes it easier to use LoadedModules w/o causing a memory
leak: ListOfModules owns the modules, and makes sure to properly clean
them in destructor.
Remove filtering functionality that is only needed in one place (LSan).
Reviewers: aizatsky
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D17470
llvm-svn: 261554
I ran the test suite yesterday and when I came back this morning the
queue_user_work_item.cc test was hung. This could be why the
sanitizer-windows buildbot keeps randomly timing out. I updated all the
usages of WaitForSingleObject involving threading events. I'm assuming
the API can reliably wait for subprocesses, which is what the majority
of call sites use it for.
While I'm at it, we can simplify some EH tests now that clang can
compile C++ EH.
llvm-svn: 261338
We were erroneously reporting 16K as the page size on Windows because
the code that does the shadow mapping was using page size instead of
allocation granularity. After fixing that, we can resolve the FIXMEs in
the Windows implementations of GetPageSize and GetMmapGranularity by
calling GetSystemInfo instead of returning hard-coded, incorrect
answers.
llvm-svn: 261233
FreeBSD does not install a number of Clang-provided headers for the
compiler in the base system due to incompatibilities between FreeBSD's
and Clang's versions. As a workaround do not use --sysroot=. on FreeBSD
until this is addressed.
llvm.org/pr26651
Differential Revision: http://reviews.llvm.org/D17383
llvm-svn: 261229
There seems to be a difference between 2.12.1 and 2.12.2 in 64-bit build.
Tested on Scientific Linux 6.6, based on RHEL.
Differential Revision: http://reviews.llvm.org/D17190
llvm-svn: 261193
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
Compiler-rt only relies on LLVM for lit support. Pushing this dependency down into the test and unitest layers will allow builtin libraries to be built without LLVM.
llvm-svn: 261105
__msan_unpoison uses intercepted memset which currently leads to a SEGV
when linking with libc++ under CentOS 7.
Differential Revision: http://reviews.llvm.org/D17263
llvm-svn: 261073
1. Add two explicit -stdlib=libstdc++ in conjunction with -static-libstdc++
2. Pass -nostdinc++ when adding include paths for libc++ built for tsan. This
prevents clang finding the headers twice which would confuse #include_next
Differential Revision: http://reviews.llvm.org/D17189
llvm-svn: 260883
FreeBSD also needs to have sanitizer_linux_libcdep.cc included,
otherwise linking will fail with "undefined reference to
`__sanitizer::GetRSS()'".
While here, tabify the FreeBSD part, similar to the other parts.
llvm-svn: 260839
r260695 caused extra push/pop instruction pair in __tsan_read1
implementation. Still, that change in InstCombine is believed to
be good, as it reduces the number of instructions performed.
Adjust the expectations to match the newly generated code.
llvm-svn: 260775
There's no obvious reason it should fail in this way but it's the only change
on the blamelist. I suspect stale lit*.cfg's from previous builds.
llvm-svn: 260672
The lit test-suite containing the unit tests needs to be explicitly specified
as an argument to lit.py since it is no longer discovered when the other tests
are run (because they are one directory deeper).
dfsan, lsan, and sanitizer_common don't show the same problem.
llvm-svn: 260669
Summary:
In some cases stack pointer register (SP) doesn't point into the thread
stack: e.g. if one is using swapcontext(). In this case LSan
conservatively tries to scan the whole thread stack for pointers.
However, thread stack (at least in glibc implementation) may also
include guard pages, causing LSan to crash when it's reading from them.
One of the solutions is to use a pthread_attr_getguardsize() to adjust
the calculated stack boundaries. However, here we're just using
IsAccessibleMemoryRange to skip guard pages and make the code (slightly)
less platform-specific.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17116
llvm-svn: 260554
This test isn't posix specific, but it doesn't pass on Windows and is
XFAILed. I suspect that this test, which is expected to fail, is causing
the hangs I'm seeing on our WinASan builder. Moving it to Posix seems
to be the cleanest way to avoid running it on Windows.
llvm-svn: 260480
It thinks that these functions don't match the function pointer type
that they are passed with:
GCDAProfiling.c(578) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(579) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(580) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
llvm-svn: 260475
that's not true in general. Instead, use a preference order to pick the
standard C++ signature 'char*(char*, int)' where possible and fall back to the
C signature 'char*(const char*, int)' only when it's unavailable.
llvm-svn: 260425
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when lsan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16859
llvm-svn: 260232
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16856
llvm-svn: 260231
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, srhines, llvm-commits
Differential Revision: http://reviews.llvm.org/D16855
llvm-svn: 260230
Summary:
This fixes duplicate test names in the test results, so:
PASS: SanitizerCommon-asan :: fopen_nullptr.c (304 of 431)
PASS: SanitizerCommon-asan :: fopen_nullptr.c (305 of 431)
is now:
PASS: SanitizerCommon-asan-i386-Linux :: fopen_nullptr.c (282 of 431)
PASS: SanitizerCommon-asan-x86_64-Linux :: fopen_nullptr.c (316 of 431)
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16850
llvm-svn: 260227
This reduces sizes of instrumented object files, final binaries,
process images, and raw profile data.
The format of the indexed profile data remain the same.
Differential Revision: http://reviews.llvm.org/D16388
llvm-svn: 260118
This is a compiler-rt part of this http://reviews.llvm.org/D15642 patch. Here,
we add a new approach for ODR violation detection.
Instead of using __asan_region_is_poisoned(g->beg, g->size_with_redzone) on
global address (that would return false now due to using private alias), we can
use new globally visible indicator symbol to perform the check.
Differential Revision: http://reviews.llvm.org/D15644
llvm-svn: 260076
The "sanitizer-windows" buildbot has been failing for two days because of this:
FAILED: cl.exe asan_report.cc
asan_scariness_score.h(60) : error C2536:
'__asan::ScarinessScore::__asan::ScarinessScore::descr' :
cannot specify explicit initializer for arrays
asan_scariness_score.h(60) : see declaration of '__asan::ScarinessScore::descr'
llvm-svn: 260059
On FreeBSD, the uc_mcontext member of ucontext_t has a member called
mc_err, which corresponds to the Linux member gregs[REG_ERR].
Reviewed by: rdivacky@FreeBSD.org
llvm-svn: 260046
The type of size and align in struct __emutls_control must be
typedef unsigned int gcc_word __attribute__((mode(word)));
to match GCC. When gcc_word is larger than size_t, which is the case
for x32, the upper extra bits are all zeros. We can use variables of
size_t to operate on size and align.
Fix one trivial C99 warning about mixed declaration and code.
Differential Revision: http://reviews.llvm.org/D16886
llvm-svn: 259824
Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.
http://reviews.llvm.org/D16824
llvm-svn: 259717
Summary:
This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.
When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.
This patch causes cmake to only build the libcxx and run the lit test-suite for
archictures in ${TSAN_SUPPORTED_ARCH}
This re-commit fixes an issue where 'check-tsan' continued to look for the
tsan'd libc++ in the directory it used to be built in.
Reviewers: hans, samsonov
Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov
Differential Revision: http://reviews.llvm.org/D16685
llvm-svn: 259542
Summary:
Since the prototype of mremap is
```
void *mremap(void *old_address, size_t old_size, size_t new_size,
int flags, ... /* void *new_address*/);
```
we need to cast new_address to void * when calling mremap. Otherwise,
the wrong value will be passed to mremap on x32.
Patch by H.J Lu!
Reviewers: kcc, eugenis, samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D16805
llvm-svn: 259540
check-tsan does not pick up the correct libc++.so. It succeeded on my machine
by picking up the libc++.so that was built before making this change.
llvm-svn: 259519
Summary:
This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.
When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.
This patch causes cmake to only build the libcxx and run the lit test-suite for
archictures in ${TSAN_SUPPORTED_ARCH}
Reviewers: hans, samsonov
Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov
Differential Revision: http://reviews.llvm.org/D16685
llvm-svn: 259512
We already disabled various tests relying on C++ ABI knowledge, but we
still tried to build in this configuration on Windows which was a
mistake.
Fixes PR26415.
llvm-svn: 259388
This patch adds support for expanding "%h" out to the machine hostname
in the LLVM_PROFILE_FILE environment variable.
Patch by Daniel Waters!
Differential Revision: http://reviews.llvm.org/D16371
llvm-svn: 259272
test/cfi/cross-dso/dlopen.cpp:67:45: warning: GCC does not allow 'aligned' attribute in this position on a function definition [-Wgcc-compat]
extern "C" void do_nothing() __attribute__((aligned(4096))) {}
llvm-svn: 258992
This change enables diagnostics when the target address for a CFI
check is out of bounds of any known library, or even not in the
limits of the address space. This happens when casting pointers to
uninitialized memory.
Ubsan code does not yet handle some of these situations correctly,
so it is still possible to see a segmentation fault instead of a
proper diagnostic message once in a while.
llvm-svn: 258879
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I am the punishment of God... If [autoconf] had not committed great sins, God would not have sent a punishment like me upon [it]."
-Genghis Khan
Reviewers: chandlerc, grosbach, bob.wilson, zaks.anna, kubabrecka, samsonov, echristo
Subscribers: iains, llvm-commits
Differential Revision: http://reviews.llvm.org/D16473
llvm-svn: 258863
* add __cfi_slowpath_diag with a 3rd parameter which is a pointer to
the diagnostic info for the ubsan handlers.
*__cfi_check gets a 3rd parameter as well.
* unify vcall/cast/etc and icall diagnostic info format, and merge
the handlers to have a single entry point (actually two points due
to abort/noabort variants).
* tests
Note that this comes with a tiny overhead in the non-diag mode:
cfi_slowpath must pass 0 as the 3rd argument to cfi_check.
llvm-svn: 258744
This is broken in the current (post-MNC) master branch.
Use EXEC_PAGESIZE instead, the same as on x86 Linux.
This change fixes startup crashes in the existing tests on AOSP
master.
llvm-svn: 258706
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
The original submittion triggered a BFD linker bug (2.24) on Aarch64 only. Before
the build bot is upgraded to more recent linker, restrict the test to be
executed only with gold linker.
llvm-svn: 258437
MSan runtime is not itself instrumented, so we need to explicitly
clear shadow for function arguments before calling user-provided
functions from runtime (e.g. we already do this for several
interceptors).
I'm still crafting a test case that would demonstrate this issue
reliably, and will commit it later today.
llvm-svn: 258339
Alexey Samsonov