Summary:
After patch https://lkml.org/lkml/2015/12/21/340 is introduced in
linux kernel, the random gap between stack and heap is increased
from 128M to 36G on 39-bit aarch64. And it is almost impossible
to cover this big range. So we need to disable randomized virtual
space on aarch64 linux.
Reviewers: llvm-commits, zatrazz, dvyukov, rengolin
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D18526
llvm-svn: 265366
We've reset thr->ignore_reads_and_writes, but forget to do
thr->fast_state.ClearIgnoreBit(). So ignores were not effective
reset and fast_state.ignore_bit was corrupted if signal handler
itself uses ignores.
Properly reset/restore fast_state.ignore_bit around signal handlers.
llvm-svn: 265288
For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting COMPILER_RT_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.
llvm-svn: 265057
This test case is meant to check whether verbose error logging works. It
does this by _failing_ to write a profile to a path corresponding to a
directory. Make this clearer by writing to a temporary directory.
Patch suggested by Sean Silva!
llvm-svn: 264817
This also makes it work on PS4 a bit better.
For running the libprofile tests on PS4, we are sneaking environment
variables through on the command line, so the extra argument for
LLVM_PROFILE_FILE was messing up the simple `argc < 2` check.
llvm-svn: 264812
This addresses PR27077. For some historical reason Darwin wasn't shipping multi3 in the compiler builtin library or in the OS builtin library. This caused building ffmpeg to fail because Polly was generating calls to multi3. It is easy enough to just add the builtin.
llvm-svn: 264750
to function names
Summary:
Hopefully this will make it easier for the next person to figure all
this out...
Reviewers: bogner, davidxl
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D18489
llvm-svn: 264680
This is implicitly needed at least by gcc-flag-compatibility.test
The thing that needs it is the `\` preceding the "default.profraw"
appended internally by clang when doing `-fprofile-use=`.
Clang uses `\` because is uses sys::path::append which will use `\` on a
Windows host. This is wrong, but I don't think there's an easy way to
solve it (maybe just always using `/` since places that accept `\` also
tend to accept `/`, but not the other way around).
llvm-svn: 264665
This change introduces routines that register and unregister all
instrumented globals in a loaded executable image.
These routines are only implemented on Darwin, where globals metadata
is expected to be placed in the __DATA,__asan_globals section.
Review: http://reviews.llvm.org/D16841
llvm-svn: 264644
This patch fixes the custom ThreadState destruction on OS X to avoid crashing when dispatch_main calls pthread_exit which quits the main thread.
Differential Revision: http://reviews.llvm.org/D18496
llvm-svn: 264627
Summary:
Hopefully this will make it easier for the next person to figure all
this out...
Reviewers: bogner, davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18490
llvm-svn: 264612
On PS4, we have to fake environment variables by passing extra command
line arguments, so the dummy test `argc > 1` was failing.
The condition is just a dummy condition that the compiler can't fold
away, so the number is arbitrary as long as the condition is false.
Increase the number it compares against.
llvm-svn: 264491
Summary:
Currently, sanitizer_common_interceptors.inc has an implicit, undocumented
assumption that the sanitizer including it has previously declared
interceptors for memset and memmove. Since the memset, memmove, and memcpy
routines require interception by many sanitizers, we add them to the
set of common interceptions, both to address the undocumented assumption
and to speed future tool development. They are intercepted under a new
flag intercept_intrin.
The tsan interceptors are removed in favor of the new common versions. The
asan and msan interceptors for these are more complex (they incur extra
interception steps and their function bodies are exposed to the compiler)
so they opt out of the common versions and keep their own.
Reviewers: vitalybuka
Subscribers: zhaoqin, llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D18465
llvm-svn: 264451
ucrtbase.dll appears to be built with some kind of cross-module
inlining, because there are calls to imported Heap* routines sprinkled
throughout the code. This inlining defeats our attempts to hotpatch
malloc, _malloc_base, and related functions. Failing to intercept an
allocation or deallocation results in a crash when the program attempts
to deallocate or reallocate memory with the wrong allocator.
This change patches the IAT of ucrtbase.dll to replace the addresses of
the imported Heap* functions with implementations provided by ASan. We
don't globally intercept the win32 Heap* functions because they are
typically used by system DLLs that run before ASan initializes.
Eventually, we may want to intercept them, but for now I think this is
the minimal change that will keep ASan stable.
Reviewers: samsonov
Differential Revision: http://reviews.llvm.org/D18413
llvm-svn: 264327
On OS X, fork() under TSan asserts (in debug builds only) because REAL(fork) calls some intercepted functions, which check that no internal locks are held via CheckNoLocks(). But the wrapper of fork intentionally holds some locks. This patch fixes that by using ScopedIgnoreInterceptors during the call to REAL(fork). After that, all the fork-based tests seem to pass on OS X, so let's just remove all the UNSUPPORTED: darwin annotations we have.
Differential Revision: http://reviews.llvm.org/D18409
llvm-svn: 264261
On OS X, internal_mmap just uses mmap, which can invoke callbacks into libmalloc (e.g. when MallocStackLogging is enabled). This can subsequently call other intercepted functions, and this breaks our Darwin-specific ThreadState initialization. Let's use direct syscalls in internal_mmap and internal_munmap. Added a testcase.
Differential Revision: http://reviews.llvm.org/D18431
llvm-svn: 264259
Summary:
Adds strnlen to the common interceptors, under the existing flag
intercept_strlen.
Removes the now-duplicate strnlen interceptor from asan and msan.
This adds strnlen to tsan, which previously did not intercept it.
Adds a new test of strnlen to the sanitizer_common test cases.
Reviewers: samsonov
Subscribers: zhaoqin, llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D18397
llvm-svn: 264195
This is necessary to support the dynamic CRT (/MD) with VS2015. In
VS2015, these symbols are no longer imported from a DLL, they provided
statically by msvcrt.lib. This means our approach of hotpatching the DLL
no longer works.
By exporting the symbols, we end up relying on the same mechanism that
we use to intercept symbols in the static CRT (/MT) case. The ASan
runtime always needs to appear first on the link line, and the linker
searches for symbol definitions from left to right. This means we can
stop hotpatching operator new and delete in the CRT, which is nice.
I think that the only reason we weren't exporting the symbols already is
because MSVC doesn't allow you to do it directly with
__declspec(dllexport). Instead, we can use
`#pragma comment(linker, "/export:foo")`, which is most of what the
attribute does under the hood. It does mean we have to write down the
mangled names of the operators, but that's not too bad.
llvm-svn: 264190
This reverts commits r264068 and r264079, and they were breaking the build and
weren't reverted in time, nor they exhibited expected behaviour from the
reviewers. There is more to discuss than just a test fix.
llvm-svn: 264150
Summary:
After patch https://lkml.org/lkml/2015/12/21/340 is introduced in
linux kernel, the random gap between stack and heap is increased
from 128M to 36G on 39-bit aarch64. And it is almost impossible
to cover this big range. So I think we need to disable randomized
virtual space on aarch64 linux.
Reviewers: kcc, llvm-commits, eugenis, zatrazz, dvyukov, rengolin
Subscribers: rengolin, aemerson, tberghammer, danalbert, srhines, enh
Differential Revision: http://reviews.llvm.org/D18003
llvm-svn: 264068
Some unit tests were failing because we didn't intercept strdup. It
turns out it works just fine on 2013 and 2015 with a small patch to the
interception logic.
llvm-svn: 264013
printf is an inline function in VS 2015, giving these tests an
unexpected extra point of coverage. This change works around that by
avoiding printf.
llvm-svn: 264010
VS 2015 moved the priority of their exception filter initializer from
XIY to XCAA. We now set ours to XCAB, which makes it run after both CRT
versions but before user constructors, as it should.
Fixes null_deref.cc and a variety of related tests with VS 2015. Only 4
failures remain.
llvm-svn: 264006
There are some places in the CRT (such as mbctype) that directly call
_malloc_base. If you are incrementally linking a binary with ASan from
before this change, this change appears to result in a linker error.
Retrying the link succeeds for some reason.
llvm-svn: 264005
Adds strchr, strchrnul, and strrchr to the common interceptors, under a new
common flag intercept_strchr.
Removes the now-duplicate strchr interceptor from asan and all 3
interceptors from tsan. Previously, asan did not intercept strchrnul, but
does now; previously, msan did not intercept strchr, strchrnul, or strrchr,
but does now.
http://reviews.llvm.org/D18329
Patch by Derek Bruening!
llvm-svn: 263992
ASan interceptors contain local statics which run before the CRT is
initialized. Thread-safe statics appear to rely on CRT-internal state,
and will crash without this flag.
llvm-svn: 263979
In VS 2015, the memset fill parameter is zero extended from one byte
instead of being copied wholesale.
The issue reproduces with existing tests if you use VS2015.
llvm-svn: 263966
`__tsan_get_report_thread` and others can crash if a stack trace is missing, let's add the missing checks.
Differential Revision: http://reviews.llvm.org/D18306
llvm-svn: 263939
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
__clear_cache on Android is identical to the version on Linux. Use __linux__
instead of __ANDROID__ as __linux__ is defined for Linux and Android.
llvm-svn: 263833
Summary:
Introducing InitializeCommonFlags accross all sanitizers to simplify
common flags management.
Setting coverage=1 when html_cov_report is requested.
Differential Revision: http://reviews.llvm.org/D18273
llvm-svn: 263820
On OS X, we have pthread_cond_timedwait_relative_np. TSan needs to intercept this API to avoid false positives when using condition variables.
Differential Revision: http://reviews.llvm.org/D18184
llvm-svn: 263782
On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
TSan unit tests run with a statically linked runtime, where interceptors don't work. To avoid aborting the process in this case, the patch replaces `DisableReexec()` with a weak `ReexecDisabled()` function which is defined to return true in unit tests.
Differential Revision: http://reviews.llvm.org/D18212
llvm-svn: 263695
This patch adds a new TSan report type, ReportTypeMutexInvalidAccess, which is triggered when pthread_mutex_lock or pthread_mutex_unlock returns EINVAL (this means the mutex is invalid, uninitialized or already destroyed).
Differential Revision: http://reviews.llvm.org/D18132
llvm-svn: 263641
On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES.
Differential Revision: http://reviews.llvm.org/D18121
llvm-svn: 263551
That change did:
-#if defined(__BIG_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
If __BYTE_ORDER__ and __ORDER_BIG_ENDIAN__ aren't defined, like
they are with MSVC, this condition is true (0 == 0).
Fixes PR26919.
llvm-svn: 263324
Summary:
Adds strlen to the common interceptors, under a new common flag
intercept_strlen. This provides better sharing of interception code among
sanitizers and cleans up the inconsistent type declarations of the
previously duplicated interceptors.
Removes the now-duplicate strlen interceptor from asan, msan, and tsan.
The entry check semantics are normalized now for msan and asan, whose
private strlen interceptors contained multiple layers of checks that
included impossible-to-reach code. The new semantics are identical to the
old: bypass interception if in the middle of init or if both on Mac and not
initialized; else, call the init routine and proceed.
Patch by Derek Bruening!
Reviewers: samsonov, vitalybuka
Subscribers: llvm-commits, kcc, zhaoqin
Differential Revision: http://reviews.llvm.org/D18020
llvm-svn: 263177
Summary:
Use InternalScopedString more extensively. This reduces the number of
write() syscalls, and reduces the chance that UBSan output will be
mixed with program output.
Reviewers: vitalybuka
Subscribers: kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D18068
llvm-svn: 263176
Now ASan can return virtual memory to the underlying OS. Portable
sanitizer runtime code needs to be aware that UnmapOrDie cannot unmap
part of previous mapping.
In particular, this required changing how we implement MmapAlignedOrDie
on Windows, which is what Allocator32 uses.
The new code first attempts to allocate memory of the given size, and if
it is appropriately aligned, returns early. If not, it frees the memory
and attempts to reserve size + alignment bytes. In this region there
must be an aligned address. We then free the oversized mapping and
request a new mapping at the aligned address immediately after. However,
a thread could allocate that virtual address in between our free and
allocation, so we have to retry if that allocation fails. The existing
thread creation stress test managed to trigger this condition, so the
code isn't totally untested.
Reviewers: samsonov
Differential Revision: http://reviews.llvm.org/D17431
llvm-svn: 263160
Summary:
Recently I saw the test `TestCases/Posix/print_cmdline.cc` failing on
FreeBSD, with "expected string not found in input". This is because
asan could not retrieve the command line arguments properly.
In `lib/sanitizer_common/sanitizer_linux.cc`, this is taken care of by
the `GetArgsAndEnv()` function, but it uses `__libc_stack_end` to get at
the required data. This variable does not exist on BSDs; the regular
way to retrieve the arguments and environment information is via the
`kern.ps_strings` sysctl.
I added this functionality in sanitizer_linux.cc, as a separate #ifdef
block in `GetArgsAndEnv()`. Also, `ReadNullSepFileToArray()` becomes
unused due to this change. (It won't work on FreeBSD anyway, since
`/proc` is not mounted by default.)
Reviewers: kcc, emaste, joerg, davide
Subscribers: llvm-commits, emaste
Differential Revision: http://reviews.llvm.org/D17832
llvm-svn: 263157
Summary: This is an initial setup in order to move some additional tests from Linux onto Posix.
I also moved decorate_proc_maps onto the Linux directory
Finally added msan's definition for "stable-runtime".
Only a test requires it, and its commit message (r248014) seems to imply
that AArch64 is problematic with MSan.
Reviewers: samsonov, rengolin, t.p.northover, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17928
llvm-svn: 263142
Currently, TSan only reports everything in a formatted textual form. The idea behind this patch is to provide a consistent API that can be used to query information contained in a TSan-produced report. User can use these APIs either in a debugger (via a script or directly), or they can use it directly from the process (e.g. in the __tsan_on_report callback). ASan already has a similar API, see http://reviews.llvm.org/D4466.
Differential Revision: http://reviews.llvm.org/D16191
llvm-svn: 263126
Summary:
__BIG_ENDIAN__ and __LITTLE_ENDIAN__ are not supported by gcc, which
eg. for ubsan Value::getFloatValue will silently fall through to
the little endian branch, breaking display of float values by ubsan.
Use __BYTE_ORDER__ == __ORDER_BIG/LITTLE_ENDIAN__ as the condition
instead, which is supported by both clang and gcc.
Noticed while porting ubsan to s390x.
Patch by Marcin Kościelnicki!
Differential Revision: http://reviews.llvm.org/D17660
llvm-svn: 263077
Until now the only exception APIs supported by gcc_personality_v0
are DWARF EH and SJLJ. This adds support for ARM EHABI as well.
This is achieved by
a) changing the function signature on ARM EHABI,
b) unwinding the stack before returning _URC_CONTINUE_UNWIND.
See "Exception Handling ABI for the ARM Architecture" for details
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf).
Patch by Timon Van Overveldt.
llvm-svn: 263010
The GCDA writer closed the arc file before unlocking it. This causes an
EBADF while unlocking the file, and opens us up to racy behavior.
Fixes PR26847.
llvm-svn: 262779
Summary:
Adds another global to asan's odr_c_test to help force the target global to
not lie at the start of bss with the gold linker where it is always
aligned.
Patch by Derek Bruening!
llvm-svn: 262678
Summary:
Hi David, SCE folks,
What is implemented in this patch is enough for the upstream libprofile to
work for PGO with the PS4 game codebase I tested ("game7" for you SCE
folks; this is with a standalone build of compiler-rt).
The first change, which is simple, is to stub out gethostname. PS4
doesn't have a simple analog for this that doesn't bring in extra
OS libraries, so for now we do not support `%h` expansion.
This is consistent with internal B#136272.
The second change implies future work, but is a simple change at present.
PS4 does not have `getenv`, so for now we will introduce a shim.
This obviously makes it impossible for many of the tests to be run since
they require setting `LLVM_PROFILE_FILE=`.
I see two paths forward:
1. In the tests we are already wrapping execution with `%run` and so by
setting a PS4-specific expansion for `%run` we can pass the information
in another way We can adapt the getenv shim as appropriate.
We will need to experiment with this internally.
Maggie, Phillip, Filipe? Any ideas? Maybe ping me internally since we
may need to get into some PS4 vagaries. I'm thinking a fake getenv
library that uses some side channel for communication.
2. Another possibility which is more verbose is to use a separate clang
invocation with `-profile-generate=<filename>` to set the filename in
each test.
This might require redundant clang invocations though which may be
undesirable for upstream. David, thoughts?
Also, this is a fairly libprofile-specific workaround, so it e.g.
doesn't help Filipe's ASan work.
Overall, this approach sounds like a bit of a hack to me.
Small detail:
InstrProfilingPort.h seems like the natural place for the getenv shim,
but GCDAProfiling.c needs it as well. InstrProfilingUtil.h is currently
the only header common between InstrProfilingFile.c and GCDAProfiling.c.
I can move the shim to InstrProfilingPort.h and add an include to
GCDAProfiling.c as per your preference David.
Reviewers: davidxl, MaggieYi, phillip.power, filcab
Subscribers: simon.f.whittaker, slingn, probinson, llvm-commits
Differential Revision: http://reviews.llvm.org/D17676
llvm-svn: 262527
Incremented the pc for each architecture in accordance with StackTrace:GetPreviousInstructionPC
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17802
llvm-svn: 262483
This code is actually never executed because all RUN lines trigger an
earlier heap-use-after-free, but there is still a compiler warning.
llvm-svn: 262276
This testcase failed on sanitizer-x86_64-linux buildbot in large parallel build due to race on
port 1234 between AddressSanitizer-i386-linux and AddressSanitizer-x86_64-linux instances of recvfrom.cc.
This patch tries to resolve the issue by relying on kernel to choose available port instead of hardcoding
its number in testcase.
Differential Revision: http://reviews.llvm.org/D17639
llvm-svn: 262204
Summary:
iOS on ARM64 doesn't unique RTTI.
Ref: clang's iOS64CXXABI::shouldRTTIBeUnique()
Due to this, pointer-equality will not necessarily work in this
architecture, across dylib boundaries.
dynamic_cast<>() will (as expected) still work, since Apple ships with
one prepared for this, but we can't rely on the type names being
pointer-equal.
I've limited the expensive strcmp check to the specific architecture
which needs it.
Example which triggers this bug:
lib.h:
struct X {
virtual ~X() {}
};
X *libCall();
lib.mm:
X *libCall() {
return new X;
}
prog.mm:
int main() {
X *px = libCall();
delete px;
}
Expected output: Nothing
Actual output:
<unknown>: runtime error: member call on address 0x00017001ef50 which does not point to an object of type 'X'
0x00017001ef50: note: object is of type 'X'
00 00 00 00 60 00 0f 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for ‘X’
Reviewers: kubabrecka, samsonov, eugenis, rsmith
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11502
llvm-svn: 262147
Currently ThreadState holds both logical state (required for race-detection algorithm, user-visible)
and physical state (various caches, most notably malloc cache). Move physical state in a new
Process entity. Besides just being the right thing from abstraction point of view, this solves several
problems:
1. Cache everything on P level in Go. Currently we cache on a mix of goroutine and OS thread levels.
This unnecessary increases memory consumption.
2. Properly handle free operations in Go. Frees are issue by GC which don't have goroutine context.
As the result we could not do anything more than just clearing shadow. For example, we leaked
sync objects and heap block descriptors.
3. This will allow to get rid of libc malloc in Go (now we have Processor context for internal allocator cache).
This in turn will allow to get rid of dependency on libc entirely.
4. Potentially we can make Processor per-CPU in C++ mode instead of per-thread, which will
reduce resource consumption.
The distinction between Thread and Processor is currently used only by Go, C++ creates Processor per OS thread,
which is equivalent to the current scheme.
llvm-svn: 262037
This test expects pthread_mutex_init in the frame #0 of thread T1 but we
get memset at frame #0 because memset that is called from pthread_init_mutex
is being intercepted by TSan
llvm-svn: 261986
Summary: Msan was intercepting version 2.1 of the pthread_create function which was making it to crash in libc because __pthread_create_2_1 modifies the stack attributes of the thread. Intercepting the correct version fixes the test SmallPreAllocatedStackThread.
Reviewers: eugenis, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17603
llvm-svn: 261980
Compiler-rt miscalculates the number of entries in the __llvm_prf_data section
on i386 Darwin. This results in a number of test failures (which we started
catching after r261344).
The fix we attempted earlier is insufficient (r261683). It caused some tests to
start passing again, but that hid the fact that we drop some data entries.
This patch should fix the real problem. It fixes the way we compute DataSize by
taking into account the way the Darwin linker lays out __llvm_prf_data.
Differential Revision: http://reviews.llvm.org/D17623
llvm-svn: 261957
Pass res instead of len as third parameter to COMMON_INTERCEPTOR_WRITE_RANGE,
because otherwise we can write to unrelated memory (in MSan) or get wrong report (in ASan).
Differential Revision: http://reviews.llvm.org/D17608
llvm-svn: 261898
This patch moves recv and recvfrom interceptors from MSan and TSan to
sanitizer_common to enable them in ASan.
Differential Revision: http://reviews.llvm.org/D17479
llvm-svn: 261841
Adjust the clobbers list. This use to work with older versions of gcc, but now
will error on newer versions (tested against 5.3) (as well as clang).
Patch by Tee Hao Wei!
llvm-svn: 261821
Summary: Building the sanitizer libraries without rpaths causes all sorts of problems when you try to use them. This simple fix should make it all work.
Reviewers: samsonov, zaks.anna
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17556
llvm-svn: 261797
Summary: As per the test the 4th element of both arrays are not initialized and hence will contain garbage values. Memcmp returns the difference between the garbage values of the 4th element which will be different on every run of the test. And since the return value of memcmp is returned from main, we are getting random exit code every time.
Reviewers: kcc, eugenis
Subscribers: mohit.bhakkad, jaydeep, llvm-commits
Differential: http://reviews.llvm.org/D17534
llvm-svn: 261739
This makes it so that component-based installations will include resource files (i.e. blacklists). My next patch will add support for component-based installations.
llvm-svn: 261699
Fix a crash when gathering value profile data on i386 Darwin.
The Darwin linker shrinks sections containing aligned structures when
padding is not explicitly added to the end of the structure. When
iterating over these structures, be sure to not walk past the end of the
section.
No tests added, since running `ninja check-profile` on i386 Darwin is
enough to reproduce the original crash.
llvm-svn: 261683
The first issue is that we longjmp from ScopedInterceptor scope
when called from an ignored lib. This leaves thr->in_ignored_lib set.
This, in turn, disables handling of sigaction. This, in turn,
corrupts tsan state since signals delivered asynchronously.
Another issue is that we can ignore synchronization in asignal
handler, if the signal is delivered into an IgnoreSync region.
Since signals are generally asynchronous, they should ignore
memory access/synchronization/interceptor ignores.
This could lead to false positives in signal handlers.
llvm-svn: 261658
Test cases definitely should not care about the complete set of architectures
supported by compiler-rt - they should only care about current
architecture that the test suite was configured for.
Introduce new lit feature to reflect this, and convert tests to use it.
llvm-svn: 261603
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
Sean Silva