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