Previously in r297800, a work-around was created to use TSC emulation on x86_64 when RDTSCP was not available on the host. A similar change was needed in the file xray_fdr_logging.cc which this patch ports over to that file.
Eventually the code should be refactored as there will be 3 locations with the same code, but that can be done as a separate step. This patch is just to keep the test from failing on my machine due to an illegal instruction since RDTSCP is not available on my x86_64 linux VM.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31909
llvm-svn: 299922
Summary:
We can move this functionality into LLVM's tools instead, as it no
longer is strictly required for the compiler-rt testing infrastructure.
It also is blocking the successful bootstrapping of the clang compiler
due to a missing virtual destructor in one of the flag parsing library.
Since this binary isn't critical for the XRay runtime testing effort
anymore (yet), we remove it in the meantime with the hope of moving the
functionality in LLVM proper instead.
Reviewers: kpw, pelikan, rnk, seurer, eugenis
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31926
llvm-svn: 299916
Summary:
Set up the proper stack frame for the thread spawned in internal_clone,
the current code does not follow ABI (and causes SEGV trying to use this
malformed frame).
Reviewers: wschmidt
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31555
llvm-svn: 299896
Avoid __attribute__((constructor)) in cpu_model.c.
Use more C99 _Complex emulation in divtc3.c. Joerg Sonnenberger added
this builtin just after the last round of C99 _Complex emulation landed
in r249514 (Oct 2015).
llvm-svn: 299784
Many things were broken:
- We stopped building most builtins on Windows in r261432 for reasons
that are not at all clear to me. This essentially reverts that patch.
- Fix %librt to expand to clang_rt.builtins-$arch.lib on Windows instead
of libclang_rt.builtins-$arch.a.
- Fix memory protection tests (trampoline, enable executable, clear
cache) on Windows. One issue was that the MSVC incremental linker
generates ILT thunks for functions with external linkage, so memcpying
the functions into the executable stack buffer wasn't working. You
can't memcpy an RIP-relative jump without fixing up the offset.
- Disable tests that rely on C99 complex library functions when using
the MSVC CRT, which isn't compatible with clang's C99 _Complex.
In theory, these could all be separate patches, but it would not green
the tests, so let's try for it all at once. Hopefully this fixes the
clang-x64-ninja-win7 bot.
llvm-svn: 299780
Summary:
During MIPS implementation work for FreeBSD, John Baldwin (jhb@FreeBSD.org)
found that gcc 6.x emits calls to __ffssi2() when compiling libc and some
userland programs in the base system.
Add it to compiler-rt's builtins, based off of the existing __ffsdi2()
implementation. Also update the CMake files and add a test case.
Reviewers: howard.hinnant, weimingz, rengolin, compnerd
Reviewed By: weimingz
Subscribers: dberris, mgorny, llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D31721
llvm-svn: 299675
Summary:
Recently, Clang enabled the check for virtual destructors
in the presence of virtual methods. That broke the bootstrap
build. Fixing it.
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31776
llvm-svn: 299672
r299658 fixed a case where InstCombine was replicating instructions instead of combining. Fixing this reduced the number of pushes and pops in the __tsan_read and __tsan_write functions.
Adjust the expectations to account for this after talking to Dmitry Vyukov.
llvm-svn: 299661
This patch addresses two issues:
* It turned out that suspended thread may have dtls->dtv_size == kDestroyedThread (-1)
and LSan wrongly assumes that DTV is available. This leads to SEGV when LSan tries to
iterate through DTV that is invalid.
* In some rare cases GetRegistersAndSP can fail with errno 3 (ESRCH). In this case LSan
assumes that the whole stack of a given thread is available. This is wrong because ESRCH
can indicate that suspended thread was destroyed and its stack was unmapped. This patch
properly handles ESRCH from GetRegistersAndSP in order to avoid invalid accesses to already
unpapped threads stack.
Differential Revision: https://reviews.llvm.org/D30818
llvm-svn: 299630
Summary:
"short" is defined as an xray flag, and buffer rewinding happens for both exits
and tail exits.
I've made the choice to seek backwards finding pairs of FunctionEntry, TailExit
record pairs and erasing them if the FunctionEntry occurred before exit from the
currently exiting function. This is a compromise so that we don't skip logging
tail calls if the function that they call into takes longer our duration.
This works by counting the consecutive function and function entry, tail exit
pairs that proceed the current point in the buffer. The buffer is rewound to
check whether these entry points happened recently enough to be erased.
It is still possible we will omit them if they call into a child function that
is not instrumented which calls a fast grandchild that is instrumented before
doing other processing.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31345
llvm-svn: 299629
Summary: Need to save `lr` before bl to aeabi_div0
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31716
llvm-svn: 299628
There are two cases to consider:
We are using the internal shell. This will still fail because of
ulimit.
We are using an external shell. In this case the difference is that we
now also constrain FileCheck to use less than 4 MB of of stack, which
it should :-)
llvm-svn: 299586
This works with a regular shell since the kernel can keep track of a
deleted cwd. Since we just keep a path string, the following
subprocess invocations fail.
I think this would also fail on windows.
llvm-svn: 299471
The patch addresses https://github.com/google/sanitizers/issues/786. Currently AsanCheckDynamicRTPrereqs prevents
dynamic ASan runtime from running in some important environments e.g. cowbuilder and fakeroot that may also work with interposition.
Let's allow users to switch off the check given that they know what they do.
Differential Revision: https://reviews.llvm.org/D31420
llvm-svn: 299188
AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.
This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.
Differential Revision: https://reviews.llvm.org/D31479
llvm-svn: 299175
TSan reports a false positive when using xpc_connection_cancel. We're missing a happens-before edge from xpc_connection_cancel to the event handler on the same connection.
Differential Revision: https://reviews.llvm.org/D31475
llvm-svn: 299086
Summary:
This is already assumed by the test suite, and by
asan_flags.cc.
Reviewers: m.ostapenko, vitalybuka, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31462
llvm-svn: 299082
I am working on improving our internal bot infrastructure. One thing
that is unique to the ps4 is that we want to run the posix tests, but
have to execute them on windows.
We currently have a local hack to use a shell on windows, but it is
pretty much impossible to get all all the tools to play nice with all
the heuristics for what is a path and what is a command line option.
This adds support LIT_USE_INTERNAL_SHELL and I will then try to fix
the tests that fail with it but adding the missing features.
llvm-svn: 299077
{M, T, E}San have fread and fwrite interceptors, let's move them to sanitizer_common to enable ASan checks as well.
Differential Revision: https://reviews.llvm.org/D31456
llvm-svn: 299061
Until llvm-xray starts running/supporting binaries that are not ELF64 we
only run the FDR tests on x86_64-linux. Previous changes caused the
tests to not actually run on x86_64.
Follow-up on D31454.
llvm-svn: 299050
When -fsanitize-address-use-after-scope is used, the instrumentation produces line numbers in stack frame descriptions. This patch make sure the ASan runtime supports this format (ParseFrameDescription needs to be able to parse "varname:line") and prepares lit tests to allow line numbers in ASan report output.
Differential Revision: https://reviews.llvm.org/D31484
llvm-svn: 299043
Summary:
This change allows us to do an end-to-end test of the FDR mode
implementation that uses the llvm-xray tooling to verify that what we
are both writing and reading the data in a consistent manner.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31454
llvm-svn: 299042
Summary:
Now that we have a platform-specific non-common lsan file, use
it to store non-common lsan data.
Reviewers: kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31472
llvm-svn: 299032
Summary:
We currently don't have any platform specific darwin
lsan modules, don't force failure if they don't exist.
Reviewers: kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31473
llvm-svn: 299031
Summary:
I know of two implementations that do this (ASan is not protecting against accessing the returned memory for now, just like malloc(0)):
SIE libc on the PS4
dlmalloc has a flag for this
This allows us to properly support this behaviour.
Reviewers: vsk, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31295
llvm-svn: 299016
The same test fails on clang-cmake-armv7-a15-full biuld bot
but passes the clang-cmake-thumbv7-a15-full.
For now, we mark it as UNSUPPORTED for armhf target.
Bug 32457 tracks it.
llvm-svn: 299005
It was XFAILed in r298974. However, the problem was not exposed on
the buildbot because hardfp flag was not passed during the test.
We can fix the CMAKE to pass the same flag as building the lib to the
RUN line to see if the problem is still there. For now, we remove the
XFAIL.
llvm-svn: 298997
Summary:
Currently the FDR log writer, upon flushing, dumps a sequence of buffers from
its freelist to disk. A reader can read the first buffer up to an EOB record,
but then it is unclear how far ahead to scan to find the next threads traces.
There are a few ways to handle this problem.
1. The reader has externalized knowledge of the buffer size.
2. The size of buffers is in the file header or otherwise encoded in the log.
3. Only write out the portion of the buffer with records. When released, the
buffers are marked with a size.
4. The reader looks for memory that matches a pattern and synchronizes on it.
2 and 3 seem the most flexible and 2 does not rule 3 out.
This is an implementation of 2.
In addition, the function handler for fdr more aggressively checks for
finalization and makes an attempt to release its buffer.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31384
llvm-svn: 298982
Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.
This also unblocks D31385, D31384, and D31345.
Reviewers: kpw, pelikan
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31452
llvm-svn: 298977
Summary:
Originally, a few tests fail for armhf target due to:
1) COMPILER_RT_ARMHF_TARGET was not set when building the lib
2) COMPILER_RT_ABI should not be defined as `__attribute__((pcs("aapcs")))` for armhf when building for both lib and tests
This address https://bugs.llvm.org//show_bug.cgi?id=32261
mulsc3_test.c is a newly exposed issue, which will be addressed separately.
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: aemerson, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31448
llvm-svn: 298974
Summary:
This prevents InternalAlloc from being called before the sanitizers
are fully initialized.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31306
llvm-svn: 298947
Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.
Reviewers: kcc, kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29995
llvm-svn: 298946
Re-land of r298714 which got reverted in r298868.
It looks like the current lit tests won't run for Apple.
Possible reason is the libname is different. (need to update
the base_lib variable of lit.cfg)
llvm-svn: 298892
Having this function in common seems to trigger a lot of unrelated
test failures. Given that this isn't really common code anyway,
move this to a new linux-specific lsan file.
llvm-svn: 298878
This test case occassionally hangs when run on powerpc. This is also a
problem on AArch64 (see https://bugs.llvm.org/show_bug.cgi?id=24389).
Reactivate this when the problem is fixed.
This could also be related to the same problem as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, and several
others that do not run reliably on powerpc.
llvm-svn: 298873
On Darwin, we're having multiple issues with using -fomit-frame-pointer in the AddressSanitizer and ThreadSanitizer runtimes, so we're actually not using -fomit-frame-pointer in the our builds of the sanitizer dylibs. This patch just pushes our internal change upstream.
The issues are usually with debuggers, profilers and other tools that unwind the stack (crash reporter), which are often simply not able to get a stack trace. And crashlogs that don't contain a stack trace are a huge problem.
Differential Revision: https://reviews.llvm.org/D31376
llvm-svn: 298859
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31291
llvm-svn: 298848
Summary:
This test fails with a false negative due to an unrelated change.
Since we expect a number of false negatives on 32-bit lsan,
disable this test on linux-i386 and linux-i686.
Reviewers: kubamracek, m.ostapenko, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31300
llvm-svn: 298847
In file included from /home/abuild/rpmbuild/BUILD/llvm/projects/compiler-rt/lib/xray/tests/unit/xray_fdr_log_printer_tool.cc:15:
../projects/compiler-rt/lib/xray/tests/../xray_fdr_logging_impl.h:221:21: error: use of undeclared identifier 'CLOCK_MONOTONIC'
wall_clock_reader(CLOCK_MONOTONIC, &TS);
^
1 error generated.
llvm-svn: 298837
Instead of std::atomic APIs for atomic operations, we instead use APIs
include with sanitizer_common. This allows us to, at runtime, not have
to depend on potentially dynamically provided implementations of these
atomic operations.
Fixes http://llvm.org/PR32274.
llvm-svn: 298833
This is failing on some of our internal bots because we're using different symbolizers. It doesn't seem important and we never test for column numbers in any other tests, so let's just remove it.
Differential Revision: https://reviews.llvm.org/D30122
llvm-svn: 298822
While it's usually a bug to call GCD APIs, such as dispatch_after, with NULL as a queue, this often "somehow" works and TSan should maintain binary compatibility with existing code. This patch makes sure we don't try to call Acquire and Release on NULL queues, and add one such testcase for dispatch_after.
Differential Revision: https://reviews.llvm.org/D31355
llvm-svn: 298820
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
llvm-svn: 298809
Asserting the result of strtok when we expect delimiter overflow is
flaky, the result depends on the random state of memory right after the
delimiters.
llvm-svn: 298743
Summary:
Original r297566 (https://reviews.llvm.org/D30802) is splitted into two parts.
This part adds CMakefile/lit.cfg support.
Reviewers: rengolin, compnerd, jroelofs, erik.pilkington
Subscribers: srhines, dberris, mgorny
Differential Revision: https://reviews.llvm.org/D31259
llvm-svn: 298714
Summary:
Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation
mode (-mthumb, -marm), it reflect's capability of given CPU.
Due to this:
- use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB
- use '.thumb' directive consistently in all affected files
- decorate all thumb functions using
DEFINE_COMPILERRT_THUMB_FUNCTION()
---------
Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 !
Reviewers: weimingz, rengolin, compnerd
Subscribers: aemerson, dim
Differential Revision: https://reviews.llvm.org/D30938
llvm-svn: 298713
Summary: Fd needs to be closed before the number gets out of scope.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31278
llvm-svn: 298685
Maxim Ostapenko