Fuchsia Clang code coverage pipeline started to use binary ids that are
embedded in profiles. This patch removes emitting symbolizer markup,
which is not necessary in the coverage pipeline anymore.
Differential Revision: https://reviews.llvm.org/D111674
This lets us reduce size of Node, similar to D111183 proposal.
Depends on D111610.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D111612
unlock corrupted backets by using s set by loop to nullptr.
Also StackDepot supports iterating without locking.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D111599
Reducing the number of iterations in that test with D111342 helped,
but the failure still occured flakily when the test is ran as part
of a large test suite.
Reducing further the number of iterations might not be good enough,
so we will skip the test if the `max_map_count` variable can be
read, and if lower than a given threshold.
Differential Revision: https://reviews.llvm.org/D111465
Test sometimes fails on buildbot (after two non-Origins executions):
/usr/bin/ld: warning: Cannot export local symbol 'dfsan_flush'
RSS at start: 4620, after mmap: 107020, after mmap+set label: 209424, after fixed map: 4624, after another mmap+set label: 209424, after munmap: 4624
/usr/bin/ld: warning: Cannot export local symbol 'dfsan_flush'
RSS at start: 4620, after mmap: 107020, after mmap+set label: 209424, after fixed map: 4624, after another mmap+set label: 209424, after munmap: 4624
/usr/bin/ld: warning: Cannot export local symbol 'dfsan_flush'
RSS at start: 4620, after mmap: 107020, after mmap+set label: 317992, after fixed map: 10792, after another mmap+set label: 317992, after munmap: 10792
release_shadow_space.c.tmp: /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/dfsan/release_shadow_space.c:91: int main(int, char **): Assertion `after_fixed_mmap <= before + delta' failed.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D111522
There is a bug reported at https://bugs.llvm.org/show_bug.cgi?id=48938
After looking through the glibc, I found the `atexit(f)` is the same as `__cxa_atexit(f, NULL, NULL)`. In orc runtime, we identify different JITDylib by their dso_handle value, so that a NULL dso_handle is invalid. So in this patch, I added a `PlatformJDDSOHandle` to ELFNixRuntimeState, and functions which are registered by atexit will be registered at PlatformJD.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D111413
1. Include <cet.h> in sanitizer_common/sanitizer_asm.h, if it exists, to
mark Intel CET support when Intel CET is enabled.
2. Define _CET_ENDBR as empty if it isn't defined.
3. Add _CET_ENDBR to function entries in assembly codes so that ENDBR
instruction will be generated when Intel CET is enabled.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D111185
This reverts commit fdf4c03522.
Breaks macOS bots, e.g. https://crbug.com/1257863.
Still figuring out if this is actually supported on macOS. Other places
that include <cet.h> only do so on Linux.
`ScudoWrappersCppTest.AllocAfterFork` was failing obscurely sometimes.
Someone pointed us to Linux's `vm.max_map_count` that can be
significantly lower on some machines than others. It turned out that
on a machine with that setting set to 65530, some `ENOMEM` errors
would occur with `mmap` & `mprotect` during that specific test.
Reducing the number of times we fork, and the maximum size allocated
during that test makes it pass on those machines.
Differential Revision: https://reviews.llvm.org/D111342
This will simplify removing id proposed by @dvyukov on D111183
Also now we have more flexiliby for traces compressio they
are not interleaving with uncompressable headers.
Depends on D111256.
Differential Revision: https://reviews.llvm.org/D111274
TestCases/stress_dtls.c was failing when we ran memprof tests for the first
time. The test checks that __tls_get_addr is not in the output for the last
run when it is possible for the interceptor __interceptor___tls_get_addr to
be in the output from stack dumps. The test actually intends to check that
the various __tls_get_addr reports don't get emitted when intercept_tls_get_addr=0.
This updates the test to also check for the following `:` and preceding `==`
which should ignore the __interceptor___tls_get_addr interceptor.
Differential Revision: https://reviews.llvm.org/D111192
Although THREADLOCAL variables are supported on Darwin they cannot be
used very early on during process init (before dyld has set it up).
Unfortunately the checked lock is used before dyld has setup TLS leading
to an abort call (`_tlv_boostrap()` is never supposed to be called at
runtime).
To avoid this problem `SANITIZER_CHECK_DEADLOCKS` is now disabled on
Darwin platforms. This fixes running TSan tests (an possibly other
Sanitizers) when `COMPILER_RT_DEBUG=ON`.
For reference the crashing backtrace looks like this:
```
* thread #1, stop reason = signal SIGABRT
* frame #0: 0x00000002044da0ae dyld`__abort_with_payload + 10
frame #1: 0x00000002044f01af dyld`abort_with_payload_wrapper_internal + 80
frame #2: 0x00000002044f01e1 dyld`abort_with_payload + 9
frame #3: 0x000000010c989060 dyld_sim`abort_with_payload + 26
frame #4: 0x000000010c94908b dyld_sim`dyld4::halt(char const*) + 375
frame #5: 0x000000010c988f5c dyld_sim`abort + 16
frame #6: 0x000000010c96104f dyld_sim`dyld4::APIs::_tlv_bootstrap() + 9
frame #7: 0x000000010cd8d6d2 libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::CheckedMutex::LockImpl(this=<unavailable>, pc=<unavailable>) at sanitizer_mutex.cpp:218:58 [opt]
frame #8: 0x000000010cd8a0f7 libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::Mutex::Lock() [inlined] __sanitizer::CheckedMutex::Lock(this=0x000000010d733c90) at sanitizer_mutex.h:124:5 [opt]
frame #9: 0x000000010cd8a0ee libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::Mutex::Lock(this=0x000000010d733c90) at sanitizer_mutex.h:162:19 [opt]
frame #10: 0x000000010cd8a0bf libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=0x000000030c7479a8, mu=<unavailable>) at sanitizer_mutex.h:364:10 [opt]
frame #11: 0x000000010cd89819 libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=0x000000030c7479a8, mu=<unavailable>) at sanitizer_mutex.h:363:67 [opt]
frame #12: 0x000000010cd8985b libclang_rt.tsan_iossim_dynamic.dylib`__sanitizer::LibIgnore::OnLibraryLoaded(this=0x000000010d72f480, name=0x0000000000000000) at sanitizer_libignore.cpp:39:8 [opt]
frame #13: 0x000000010cda7aaa libclang_rt.tsan_iossim_dynamic.dylib`__tsan::InitializeLibIgnore() at tsan_interceptors_posix.cpp:219:16 [opt]
frame #14: 0x000000010cdce0bb libclang_rt.tsan_iossim_dynamic.dylib`__tsan::Initialize(thr=0x0000000110141400) at tsan_rtl.cpp:403:3 [opt]
frame #15: 0x000000010cda7b8e libclang_rt.tsan_iossim_dynamic.dylib`__tsan::ScopedInterceptor::ScopedInterceptor(__tsan::ThreadState*, char const*, unsigned long) [inlined] __tsan::LazyInitialize(thr=0x0000000110141400) at tsan_rtl.h:665:5 [opt]
frame #16: 0x000000010cda7b86 libclang_rt.tsan_iossim_dynamic.dylib`__tsan::ScopedInterceptor::ScopedInterceptor(this=0x000000030c747af8, thr=0x0000000110141400, fname=<unavailable>, pc=4568918787) at tsan_interceptors_posix.cpp:247:3 [opt]
frame #17: 0x000000010cda7bb9 libclang_rt.tsan_iossim_dynamic.dylib`__tsan::ScopedInterceptor::ScopedInterceptor(this=0x000000030c747af8, thr=<unavailable>, fname=<unavailable>, pc=<unavailable>) at tsan_interceptors_posix.cpp:246:59 [opt]
frame #18: 0x000000010cdb72b7 libclang_rt.tsan_iossim_dynamic.dylib`::wrap_strlcpy(dst="\xd2", src="0xd1d398d1bb0a007b", size=20) at sanitizer_common_interceptors.inc:7386:3 [opt]
frame #19: 0x0000000110542b03 libsystem_c.dylib`__guard_setup + 140
frame #20: 0x00000001104f8ab4 libsystem_c.dylib`_libc_initializer + 65
...
```
rdar://83723445
Differential Revision: https://reviews.llvm.org/D111243
When using a static libunwind, the check_memcpy.c can fail because it checks
that tsan intercepted all memcpy/memmoves in the final binary. Though if the
static libunwind is not instrumented, then this will fail because it may contain
regular memcpy/memmoves.
This adds a new REQUIRES check for ensuring that this test won't run unless a
dynamic libunwind.so is provided.
Differential Revision: https://reviews.llvm.org/D111194
Now we can avoid scanning the stack on fast path.
The price is the false stack trace with probability of the hash collision.
This increase performance of lsan by 6% and pre-requirement for stack compression.
Depends on D111182.
Reviewed By: morehouse, dvyukov
Differential Revision: https://reviews.llvm.org/D111183
1. Include <cet.h> in sanitizer_common/sanitizer_asm.h to mark Intel CET
support when Intel CET is enabled.
2. Add _CET_ENDBR to function entries in assembly codes so that ENDBR
instruction will be generated when Intel CET is enabled.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D111185
On Ubuntu Focal x13 is used by something in the process of calling
sched_yield. Causing the test to fail depending on when the thread
is stopped.
Adding x14 works around this and the test passes consistently.
Not switching to only x14 because that could make other platforms
fail. With both we'll always find at least one and even if both
values are present we'll only get one report.
Reviewed By: oontvoo, vitalybuka
Differential Revision: https://reviews.llvm.org/D110931
These runtime callbacks are supposed to be non-instrumented,
we can't handle runtime recursion well, nor can we afford
explicit recursion checks in the hot functions (memory access,
function entry/exit).
It used to work (not crash), but it won't work with the new runtime.
Mark all runtime callbacks as non-instrumented.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D111157
This is to account for the change that made CountersPtr in __profd_
relative which landed in a1532ed275.
That change hasn't updated the raw profile version, and while the
profile layout stayed the same, profiles generated by tip-of-tree
LLVM are incompatible with 13.x tooling.
Differential Revision: https://reviews.llvm.org/D111123
Print meaningful stack frames for stack/tls races
(instead of PC 1/2 that don't symbolize).
Imitate stack/tls writes after we create and initialize
the new thread, otherwise the races are not detected.
This is re-submit of the following reverted commits,
but without tests as they failed on a number of OSes/arches:
"tsan: fix and test detection of TLS races"
"tsan: fix tls_race3 test on darwin"
"tsan: print a meaningful frame for stack races"
Differential Revision: https://reviews.llvm.org/D111147
Whenever we call cur_thread_init, we call cur_thread on the next line.
So make cur_thread_init return the current thread directly.
Makes code a bit shorter, does not affect codegen.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D110384
A bunch of MTE tests like ./ScudoUnitTest-aarch64-Test/MemtagTest.StoreTags
can fail on aarch64-linux if the kernel doesn't support the tagged address ABI. It looks like
the call to prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0) can return -1, which
casted to an unsigned int and masked will return a value not equal to
PR_MTE_TCF_NONE, meaning systemDetectsMemoryTagFaultsTestOnly can return an incorrect value.
This updates the check to account for a failing prctl call.
Differential Revision: https://reviews.llvm.org/D110888
The LE Power sanitizer bot fails when testing standalone compiler-rt due to
an MSAN test warning introduced by -Wbitwise-instead-of-logical. As this option
along with -Werror is enabled on the bot, the test failure occurs.
This patch updates msan_test.cpp to fix the warning introduced by the
-Wbitwise-instead-of-logical.
Previously, PrintASCII would print the string "\ta" as "\x09a". However,
in C/C++ those strings are not the same: the trailing 'a' is part of the
escape sequence, which means it's equivalent to "\x9a". This is an
annoying quirk of the standard. (See
https://eel.is/c++draft/lex.ccon#nt:hexadecimal-escape-sequence)
To fix this, output three-digit octal escape sequences instead. Since
octal escapes are limited to max three digits, this avoids the problem
of subsequent characters unintentionally becoming part of the escape
sequence.
Dictionary files still use the non-C-compatible hex escapes, but I
believe we can't change the format since it comes from AFL, and
libfuzzer never writes such files, it only has to read them, so they're
not affected by this change.
Differential revision: https://reviews.llvm.org/D110920
Use of space as a separator for options is problematic for wrapper
scripts (i.e. implementations of `%run`) that have to marshall
environment variables to target different than the host.
Rather than requiring every implementation of `%run` to support spaces
in `TSAN_OPTIONS` it is simpler to fix this single test case.
rdar://83637067
Differential Revision: https://reviews.llvm.org/D110967
Previously for mem* intrinsics we only incremented the access count for
the first word in the range. However, after thinking it through I think
it makes more sense to record an access for every word in the range.
This better matches the behavior of inlined memory intrinsics, and also
allows better analysis of utilization at a future date.
Differential Revision: https://reviews.llvm.org/D110799
rG210d72e9d6b4a8e7633921d0bd7186fd3c7a2c8c moved the check from
builtin-config-ix to config-ix so that the check would be made even when
the builtins are not built. However, now the check is no longer made
when the builtins are built standalone which causes the builtins to fail
to build.
Add the check back to builtins-config-ix so that the check gets
performed both when the builtins are not built, and when they are built
standalone.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D110879
Writing zeros to shadow (including checking for existing zero) is now ~2x
faster on one example.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D110733
ad890aa232 landed a test without
using the `%run` prefix which means the test fails to run for
platforms that need it (e.g. iOS simulators).
This patch adds the `%run` prefix. While we're here also split
the single `RUN` line into two to make debugging easier.
rdar://83637296
Differential Revision: https://reviews.llvm.org/D110734
check-orc-rt had no cmake target dependency on orc or llvm-jitlink, which
could lead to regression test failures in compiler-rt. This patch should
fix the issue.
Patch by Jack Andersen (jackoalan@gmail.com). Thanks Jack!
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D110659
Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binary
IDs. This means padding should be emitted after binary IDs are emitted to
ensure everything else is aligned. This patch adds padding after each binary ID
to ensure the next binary ID size is 8-byte aligned. This also adds extra
checks to ensure we aren't reading corrupted data when printing binary IDs.
Differential Revision: https://reviews.llvm.org/D110365
Commit 354ded67b3 ("tsan: align ThreadState to cache line")
did an incomplete thing. It marked ThreadState as cache line
aligned, but the thread local ThreadState instance is declared
as an aligned char array with hard-coded 64-byte alignment.
On PowerPC cache line size is 128 bytes, so the hard-coded
64-byte alignment is not enough.
Use cache line alignment consistently.
Differential Revision: https://reviews.llvm.org/D110629
GWP-ASan's `AllocatorState` was recently extended with a
`AllocatorVersionMagic` structure required so that GWP-ASan bug reports
can be understood by tools at different versions.
On Fuchsia, this in included in the `scudo::Allocator` structure, and
by having non-zero initializers, this effectively moved the static
allocator structure from the `.bss` segment to the `.data` segment, thus
increasing (significantly) the size of the libc.
This CL proposes to initialize the structure with its magic numbers at
runtime, allowing for the allocator to go back into the `.bss` segment.
I will work on adding a test on the Scudo side to ensure that this type
of changes get detected early on. Additional work is also needed to
reduce the footprint of the (large) memory-tagging related structures
that are currently part of the allocator.
Differential Revision: https://reviews.llvm.org/D110575
The trace tests crashed on darwin because of some thread
initialization issues (thread initialization is somewhat
different on darwin).
Instead of starting real threads, create a new ThreadState
in the main thread. This makes the tests more unit-testy
and hopefully won't crash on darwin (there is almost no
platform-specific code involved now).
This will also help with future trace tests that will need
more than 1 thread. Creating more than 1 real thread and
dispatching test actions across multiple threads in the
required deterministic order is painful.
Depends on D110539.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110546
Currently detection of races with TLS/stack initialization
is broken because we imitate the write before thread initialization,
so it's modelled with a wrong thread/epoch.
Fix that and add a test.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110538
There are 2 reasons to do this:
1. We place hot data in the first cache line of ThreadState,
this assumed that it's cache-line-aligned but we never actually
enforced it (or it was lost at some point).
2. The new vector clock uses vector instructions and requires
data alignment. Later the new vector clock will be embedded in
ThreadState, then ensuring vector clock alignment will be
impossible w/o ThreadState alignment.
Depends on D110519.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110520
Currently the shadow stack is located in the trace memory mapping.
The new tsan runtime will remove the trace memory mapping.
Move the shadow stack into ThreadState as a preparation step.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110519
Renames StartAddress and EndAddress members to Start and End.
Adds contains and overlap methods.
Adds a constructor from an address and size.
These changes are counterparts to LLVM commits ef391df2b6, c0d889995e, and
37f1b7a3f3.
It's only used during race reporting.
There is no point in polluting the main header file with it.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D110470
This adds REQUIRES: shared_cxxabi to a bunch of tests that would fail if this
weak reference in sanitizer common was undefined. This is necessary in cases
where libc++abi.a is statically linked in. Because there is no strong reference
to __cxa_demangle in compiler-rt, then if libc++abi is linked in via a static
archive, then the linker will not extract the archive member that would define
that weak symbol. This causes a handful of tests to fail because this leads to
the symbolizer printing mangled symbols where tests expect them demangled.
Technically, this feature is WAI since sanitizer runtimes shouldn't fail if
this symbol isn't resolved, and linking statically means you wouldn't need to
link in all of libc++abi. As a workaround, we can simply make it a requirement
that these tests use shared libc++abis.
Differential Revision: https://reviews.llvm.org/D109639
The stress test does various assorted things
(memory accesses, function calls, atomic operations,
thread creation/join, intercepted libc calls)
in multiple threads just to stress various parts
of the runtime.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110416
Add a test for __tsan_flush_memory() and for background
flushing of the runtime memory.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110409
In build_symbolizer.sh we can safely remove the -eu argument from the shebang (which is an unportable construct), as the scripts sets **-e** and **-u** already.
Differential Revision: https://reviews.llvm.org/D110039
This is an ORC-runtime counterpart to LLVM commit ef391df2b6, and the
motivation is the same: to move to a shorter name to improve the ergonomics of
this type before it's more widely adopted.
This test specifically checks that profiles are not mergeable if there's a
change in the CounterPtr in the profile header. The test manually changes
CounterPtr by explicitly calling memset on some offset into the profile file.
This test would fail if binary IDs were emitted because the offset calculation
does not take into account the binary ID sizes.
This patch updates the test to use types provided in profile/InstrProfData.inc
to make it more resistant to profile layout changes.
Differential Revision: https://reviews.llvm.org/D110277
Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binary
IDs. This means padding should be emitted after binary IDs are emitted to
ensure everything else is aligned. This patch accounts for that padding in
__llvm_write_binary_ids.
Differential Revision: https://reviews.llvm.org/D110188
Remove nmissed_expected variable.
It's a leftover from removed "expected race" feature and is never incremented.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110321
tsan_rtl.h is very huge and contains too many things.
Move FastState and Shadow types into a new tsan_shadow.h file.
This also allows to use FastState/Shadow in other header files
without creating circular dependencies (which most likely will
happen today).
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110272
Fix few remaining cases where we use u64 instead of the new RawShadow type.
Depends on D110265.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110266
Add a test for a trace corner case that lead to a bug
in experimental runtime replacement.
Since it passes with the current runtime it makes sense
to submit it on its own.
Depends on D110264.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110265
DontDumpShadow is used only in InitializeShadowMemory which is Go-only.
Depends on D110263.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110264
Remove unnecessary enum values in the memory profiler.
There is no point in spelling them, it can only lead to bugs
and larger diffs when values are added/removed.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110263
intercept-rethrow-exception.cc fails when running runtimes tests if linking in
a hermetic libc++abi. This is because if libc++abi is used, then asan expects
to intercept __cxa_rethrow_primary_exception on linux, which should unpoison the
stack. If we statically link in libc++abi though, it will contain a strong
definition for __cxa_rethrow_primary_exception which wins over the weakly
defined interceptor provided by asan, causing the test to fail by not unpoisoning
the stack on the exception being thrown.
It's likely no one has encountered this before and possible that upstream tests
opt for dynamically linking where the interceptor can work properly. An ideal
long term solution would be to update the interceptor and libc++[abi] APIs to
work for this case, but that will likely take a long time to work out. In the
meantime, since the test isn't necessarily broken, we can just add another
REQUIRES check to make sure that it's only run if we aren't statically linking
in libc++abi.
Differential Revision: https://reviews.llvm.org/D109938
Specifying .global and .weak causes a compiler warning:
warning: __sigsetjmp changed binding to STB_WEAK
Specifying only .weak should have the same effect without causing a
warning.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D110178
Write uptime in real time seconds for every mem profile record.
Uptime is useful to make more sense out of the profile,
compare random lines, etc.
Depends on D110153.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110154
We do query it every 100ms now.
(GetRSS was fixed to not be dead slow IIRC)
Depends on D110152.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110153
BackgroundThread function is quite large,
move mem profile initialization into a separate function.
Depends on D110151.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110152
We allocate things from the internal allocator,
it's useful to know how much it consumes.
Depends on D110150.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110151
We currently query number of threads before reading /proc/self/smaps.
But reading /proc/self/smaps can take lots of time for huge processes
and it's retries several times with different buffer sizes.
Overall it can take tens of seconds. This can make number of threads
significantly inconsistent with the rest of the stats.
So query it after reading /proc/self/smaps.
Depends on D110149.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110150
Include info about MBlock/SyncObj memory consumption in the memory profile.
Depends on D110148.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D110149
We account low and high ranges, but forgot abount the mid range.
Account mid range as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110148
ScopedInterceptor::Enable/DisableIgnores is only used for some special cases.
Unline them from the common interceptor handling.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D110157
Switch Java heap move to the new scheme required for the new tsan runtime.
Instead of copying the shadow we reset the destination range.
The new v3 trace contains addresses of accesses, so we cannot simply copy the shadow.
This can lead to false negatives, but cannot lead to false positives.
Depends on D110159.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D110190
Pass -msse4.2 flag to the tests the same way we do for the runtime.
Layout of some structs in the runtime headers depends on the flag
(TSAN_VECTORIZE), so we need it to be consistent across the runtime
and tests.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D110192
CallUserSignalHandler function is quite large and complex.
Move errno spoiling reporting into a separate function.
No logical changes.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D110159
dlsym calls into dynamic linker which calls malloc and other things.
It's problematic to do it during the actual exit, because
it can happen from a singal handler or from within the runtime
after we reported the first bug, etc.
See https://github.com/google/sanitizers/issues/1440 for an example
(captured in the added test).
Initialize the callbacks during startup instead.
Depends on D110159.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D110166
When setting the report path, recursively create the directory as
needed. This brings the profile path support for memprof on par with
normal PGO. The code was largely cloned from __llvm_profile_recursive_mkdir
in compiler-rt/lib/profile/InstrProfilingUtil.c.
Differential Revision: https://reviews.llvm.org/D109794
To intercept the functions in Win11's ntdll.dll, we need to use the trampoline
technique because there are bytes other than 0x90 or 0xcc in the gaps between
exported functions. This patch adds more patterns that appear in ntdll's
functions.
Bug: https://bugs.llvm.org/show_bug.cgi?id=51721
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D109941
The current code writes the pc-table at the process startup,
which may happen before the common_flags() are initialized.
Move writing to the process end.
This is consistent with how we write the counters and avoids the problem with the uninitalized flags.
Add prints if verbosity>=1.
Reviewed By: kostik
Differential Revision: https://reviews.llvm.org/D110119
Currently we set thr->tctx after OnStarted callback
taking thread registry mutex again and searching for the context.
But OnStarted already runs under the thread registry mutex
and has access to the context, so set it in the OnStarted.
This makes code simpler and faster.
Depends on D110132.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110133
Thread state functions are split into 2 parts:
tsan entry function (e.g. ThreadStart) and thread registry
state change callback (e.g. OnStart). Currently these
pairs of functions are located far from each other and
in reverse order. This makes it hard to read and follow the logic.
Reorder the code so that OnFoo directly follows ThreadFoo.
No other code changes.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110132
Some of the DPrintf's currently produce -Wformat warnings if enabled.
Fix these format strings.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D110131
When running tests like SanitizerCommon-asan-x86_64-Linux :: Linux/crypt_r.cpp,
it may attempt to use the host header crypt.h rather than a sysroot header.
This is significant in the event where struct crypt_data defined on host is
different from the sysroot used to make the sanitizer runtime libraries. This
can result in logical differences between the expected size/layout of struct
crypt_data known by sanitizers and the strict crypt_data provided by the host crypt.h.
Since tests should still use the CMAKE_SYSROOT, this ensures that CMAKE_SYSROOT
is propagated to compiler-rt tests.
Differential Revision: https://reviews.llvm.org/D109796
We hit some undefined symbol errors to 128-bit floating point functions when linking this test.
ld.lld: error: undefined symbol: __multf3
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced 4 more times
>>> did you mean: __muldf3
>>> defined in: /usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a
Host libc expects these to be defined, and compiler-rt will only define these
for certain platforms (see definition for CRT_LDBL_128BIT). Since we likely
can't do anything about the host libc, we can at least restrict the test to
check that these functions are supported.
Differential Revision: https://reviews.llvm.org/D109709
On Fuchsia, killing or exiting a process that has a thread listening to its own process's debugger exception channel can hang. Zircon may kill all the threads, send a synthetic exceptions to debugger, and wait for the debugger to have received them. This means the thread listening to the debug exception channel may be killed even as Zircon is waiting for that thread to drain the exception channel, and the process can become stuck in a half-dead state.
This situation is "weird" as it only arises when a process is trying to debug itself. Unfortunately, this is exactly the scenario for libFuzzer on Fuchsia: FuzzerUtilFuchsia spawns a crash-handling thread that acts like a debugger in order to be able to rewrite the crashed threads stack and resume them into libFuzzer's usual POSIX signal handlers. In practice, approximately 25% of fuzzers appear to hang on exit, after generating output and artifacts. These processes hang around until the platform is torn done, which is typically a ClusterFuzz VM. Thus, real-world impact has been somewhat mitigated. The issue should still be resolved for local users, though.
This change improves the behavior of exit() in libFuzzer by adding an atexit handler which closes an event shared with the crash handling thread. This signals to the crash handler that it should close the exception channel and be joined before the process actually exits.
Reviewed By: charco
Differential Revision: https://reviews.llvm.org/D109258
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
Previously we used a global Allocator-scope mutex to lock when adding a
deallocation to the MIB cache. This resulted in a lot of contention.
Instead add and use per-set mutexes.
Along with this, we now need to remove the global miss and access count
variables and instead utilize the per-set statistics to report the
overall miss rate.
Differential Revision: https://reviews.llvm.org/D109853
Previously we used the minimum deployment target used for the platform
(e.g. iOS is 9.0). Unfortunately this leads to ABI incompatibilities with
arm64e devices running newer OSs. In particular the following TSan test
cases that used libcxx would fail due to the ABI mismatch.
* Darwin/libcxx-shared-ptr-recursive.mm
* Darwin/libcxx-shared-ptr-stress.mm
* Darwin/libcxx-shared-ptr.mm
* libcxx/std_shared_ptr.cpp
Given that arm64e is not ABI stable we should ideally match the
deployment target for sanitizer runtimes and their tests cases to the
device when building for arm64e. Unfortunately having a mixed deployment
target (based on architecture) isn't currently supported by the build system
and is non-trivial to implement.
As a stop-gap measure this patch changes the sanitizer test suites (but not the
sanitizer runtimes themselves) to use a newer deployment target when
targetting arm64e.
The deployment target used for arm64e is the SDK version because this
"should" match the OS version running on the target device (it is a
configuration error to not match them).
rdar://83080611
9ee64c3746 has started using
COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG inside scudo. However,
the relevant CMake check was performed in builtin-config-ix.cmake,
so the definition was missing when builtins were not built. Move
the check to config-ix.cmake, so that it runs unconditionally of
the components being built.
Fixes PR#51847
Differential Revision: https://reviews.llvm.org/D109812
On x86_64-unknown-linux-gnu, `-m32` tests set LD_LIBRARY_PATH to
`config.compiler_rt_libdir` (`$build/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu`)
instead of i386-unknown-linux-gnu, so `-shared-libsan` executables
cannot find their runtime (e.g. `TestCases/replaceable_new_delete.cpp`).
Detect -m32 and -m64 in config.target_cflags, and adjust `config.compiler_rt_libdir`.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108859
Some setjmp calls within libc cannot be intercepted while their matching
longjmp calls can be. This causes problems if our setjmp/longjmp
interceptors don't use the exact same format as libc for populating and
reading the jmp_buf.
We add a magic field to our jmp_buf and populate it in setjmp. This
allows our longjmp interceptor to notice when a libc jmp_buf is passed
to it.
See discussion on https://reviews.llvm.org/D109699 and
https://reviews.llvm.org/D69045.
Fixes https://github.com/google/sanitizers/issues/1244.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D109787
This updates llvm/utils/sysroot.py to include the "DIA SDK" folder in the
sysroot.
It also updates the build to look for the DIA SDK there if a sysroot is set.
This requires moving LLVM_WINSYSROOT to config-ix.cmake.
For the GN build, I chose to pass a qualified path to diaguids in libs instead
of pushing a config with a `/libpath:` flag. The former requires a GN with
https://gn-review.googlesource.com/c/gn/+/12200, the latter requires D109624.
The former is more like the cmake build, arguably a bit simpler, and it's
easier to check for the wrong GN revision and easier to update GN.
Differential Revision: https://reviews.llvm.org/D109708
This patch use the same way as the https://reviews.llvm.org/rGfe1fa43f16beac1506a2e73a9f7b3c81179744eb to handle the thread local variable.
It allocates 2 * pointerSize space in GOT to represent the thread key and data address. Instead of using the _tls_get_addr function, I customed a function __orc_rt_elfnix_tls_get_addr to get the address of thread local varible. Currently, this is a wip patch, only one TLS relocation R_X86_64_TLSGD is supported and I need to add the corresponding test cases.
To allocate the TLS descriptor in GOT, I need to get the edge kind information in PerGraphGOTAndPLTStubBuilder, So I add a `Edge::Kind K` argument in some functions in PerGraphGOTAndPLTStubBuilder.h. If it is not suitable, I can think further to solve this problem.
Differential Revision: https://reviews.llvm.org/D109293
Add integration tests for dyld interposition: DYLD_LIBRARY_PATH and
DYLD_INSERT_LIBRARIES.
DYLD_INSERT_LIBRARIES is also relevant for TSan thread
finalization/destruction sequence in the presence of additional pthread
introspection hooks (libBacktraceRecording.dylib for Xcode 'Queue
Debugging' feature).
rdar://78739125
Differential Revision: https://reviews.llvm.org/D109332
Don't print stderr to commandline when configuring compiler-rt for
darwin platforms. NFC.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D108156
Before, COMPILER_RT_TEST_COMPILER was used which pointed to a C compiler. While
it is incorrect to assume either of these is the default compiler, using the
C++ one allows for linking cpp tests.
Differential Revision: https://reviews.llvm.org/D109207
Previously the test was failing on platforms where `long` was less than
64-bits wide (e.g. older WatchOS simulators and arm64_32) because the
`padding` field was too small.
The test currently relies on the `my_object->isa` being scribbled or
left unmodified after `my_object` is freed. However, this was not the
case because the `isa` pointer intersected with
`ChunkHeader::free_context_id`. `free_context_id` starts at the
beginning of user memory but it only initialized once the memory is
freed. This caused the `isa` pointer to change after it was freed
leading to the test crashing.
To fix this the `padding` field has been made explicitly 64-bits wide
(same size as `ChunkHeader::free_context_id`).
rdar://75806757
Differential Revision: https://reviews.llvm.org/D109409
I found that the initial corpus allocation of fork mode has certain defects.
I designed a new initial corpus allocation strategy based on size grouping.
This method can give more energy to the small seeds in the corpus and
increase the throughput of the test.
Fuzzbench data (glibfuzzer is -fork_corpus_groups=1):
https://www.fuzzbench.com/reports/experimental/2021-08-05-parallel/index.html
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D105084
Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with a new **set_cover_merge=1** flag.
This greedy set cover implementation gives a substantially smaller final corpus (40%-80% less testcases) while preserving the same features/coverage. At the same time, the execution time penalty is not that significant (+50% for ~1M corpus files and far less for smaller corpora). These results were obtained by comparing several targets with varying size corpora.
Change `Merger::CrashResistantMergeInternalStep` to collect all features from each file and not just unique ones. This is needed for the set cover algorithm to work correctly. The implementation of the algorithm in `Merger::SetCoverMerge` uses a bitvector to store features that are covered by a file while performing the pass. Collisions while indexing the bitvector are ignored similarly to the fuzzer.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D105284
We've been seeing this test return 31 instead of 32 for the "functions"
line in this test on our AArch64 bots.
One possible cause is some of the children not finishing in time
before the llvm-profdata commands are run, if the machine is heavily loaded.
Wait for all the children to finish before exiting the parent.
Reviewed By: zequanwu
Differential Revision: https://reviews.llvm.org/D109222
This is important as with exceptions enabled, non-POD allocas often have
two lifetime ends: the exception handler, and the normal one.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108365
The Solaris buildbots have been broken for some time:
In file included from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/asan_interceptors.cpp:174:
/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4000:19: error: use of undeclared identifier 'wordexp_wrde_dooffs'
((flags & wordexp_wrde_dooffs) ? p->we_offs : 0) + p->we_wordc;
^
This was caused by D108646 <https://reviews.llvm.org/D108646>; the fix is
equivalent to D108838 <https://reviews.llvm.org/D108838>.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D109193
Similar to D97585.
D25456 used `S_ATTR_LIVE_SUPPORT` to ensure the data variable will be retained
or discarded as a unit with the counter variable, so llvm.compiler.used is
sufficient. It allows ld to dead strip unneeded profc and profd variables.
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D105445
[ubsan] warn inside the sigaction interceptor if static linking is suspected, and continue instead of crashing on null deref
Reviewed By: kostik
Differential Revision: https://reviews.llvm.org/D109081
Newer Xcode toolchains ship a new otool implementation that prints out
section contents in a slightly different way than otool-classic. Specify
"-V" to otool to get the expected test output.
Differential Revision: https://reviews.llvm.org/D108929
ASan, LSan, MSan and UBSan all allow to use environment variable `*SAN_SYMBOLIZER_PATH` to pass the symbolizer path, this patch add `TSAN_SYMBOLIZER_PATH` to TSan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108911
In reviews.llvm.org/D108316 I missed a few instances of REAL(strlen) and
this change fixes that, as well as restoring one that seems like it
shouldn't have been changed.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108843
In this mode libc++ headers end up in two directories:
* include/<triple>/c++/v1 for the site config header
* include/c++/v1 for everything else
Also switch from -I to -isystem.
Differential Revision: https://reviews.llvm.org/D108841
Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.
Differential Revision: https://reviews.llvm.org/D108242
qsort can reuse qsort_r if available.
bsearch always passes key as the first comparator argument, so we
can use it to wrap the original comparator.
Differential Revision: https://reviews.llvm.org/D108751
We have to avoid calling renameat2 and clone on FreeBSD.
Additionally, the mcontext structure has different members.
Reviewed By: jrtc27, luismarques
Differential Revision: https://reviews.llvm.org/D103886
Breaks realpath(, nullptr) for all sanitizers.
Somehow INTERCEPT_FUNCTION and INTERCEPT_FUNCTION_VER return
false even if everything seemingly right.
And this is the issue for COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN.
There is a check in every sanitlizer:
if (!INTERCEPT_FUNCTION_VER(name, ver) && !INTERCEPT_FUNCTION(name))
For non-versioned interceptors when INTERCEPT_FUNCTION returns false
it's not considered fatal, and it just prints a warning.
However INTERCEPT_FUNCTION_VER in this case will fallback to
INTERCEPT_FUNCTION replacing realpath with wrong version.
We need to investigate that before relanding the patch.
This reverts commit faef0d042f.
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Handle the case of wordexp being invoked with WRDE_DOOFFS and
we.we_offs set to a positive value, which will result in NULL
entries prepended to the result. With this change the entire
result, containing both NULL and actual entries, is unpoisoned.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108646
* c_api_tests was failing to build after the API change to
__orc_rt_CWrapperFunctionResultAllocate
* wrapper_function_utils_test was causing an assertion failure, because
it was creating a result for `void(void)` with Size = 0, but seeing an
uninitialized pointer, which it considered to be an out-of-bound
error.
I noticed locally that making modifications to c_api.h is not causing
these unit tests to be rebuilt, which may be how the bug slipped in in
the first place.
Differential Revision: https://reviews.llvm.org/D108649
Fixes a regression when the allocator is disabled, and a dirty
allocation is re-used. This only occurs when the allocator is disabled,
so a test-only fix, but still necessary.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108650
Set SA_SIGINFO only if we set sighandler, or we can set the flag, and
return it as 'old' without actual sigaction set.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D108616
* Cannot use sizeof() on another union member
* nullptr vs NULL
* () vs (void)
Incidentally, fix an incorrect comment about memory ownership on the
argument to __orc_rt_CreateCWrapperFunctionResultFromOutOfBandError,
which is copied, not moved.
llvm-libc is expected to be built with sanitizers and not use interceptors in
the long run. For now though, we have a hybrid process, where functions
implemented in llvm-libc are instrumented, and glibc fills and sanitizer
interceptors fill in the rest.
Current sanitizers have an invariant that the REAL(...) function called from
inside of an interceptor is uninstrumented. A lot of interceptors call strlen()
in order to figure out the size of the region to check/poison. Switch these
callsites over to the internal, unsanitized implementation.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108316
WrapperFunctionResult no longer supports wrapping constant data, so this patch
provides direct non-const access to the wrapped data. Since wrapped data can now
be written, the WrapperFunctionResult::allocate method can be simplified to
return a WrapperFunctionResult.
This is essentially the same change (and with the same motivation) as LLVM
commit 8b117830b1, but applied to the ORC runtime's WrapperFunctionResult code.
In the raw profile, binary ids immediately follow the header so when
computing counters offset we need to account for the new section.
Differential Revision: https://reviews.llvm.org/D108608
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
This avoids pulling in all of them if only one of them is needed
(if builtins are built without -ffunction-sections), and matches how
the similar aliases for AEABI are set up.
Differential Revision: https://reviews.llvm.org/D107815
With unquoted ${CMAKE_CXX_FLAGS}, the REGEX fails when it's empty:
```CMake Error at lib/scudo/standalone/CMakeLists.txt:14 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.```
We recently enabled crt for powerpc in
https://reviews.llvm.org/rGb7611ad0b16769d3bf172e84fa9296158f8f1910.
And we started to see some unexpected error message when running
check-runtimes.
eg:
https://lab.llvm.org/buildbot/#/builders/57/builds/9488/steps/6/logs/stdio
line 100 - 103:
"
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
clang-14: error: unknown argument: '-m64 -fno-function-sections'
"
Looks like we shouldn't strip the space at the beginning,
or else the command line passed to subprocess won't work well.
Reviewed By: phosek, MaskRay
Differential Revision: https://reviews.llvm.org/D108329
Change 636428c727 enabled BlockingRegion hooks for pthread_once().
Unfortunately this seems to cause crashes on Mac OS X which uses
pthread_once() from locations that seem to result in crashes:
| ThreadSanitizer:DEADLYSIGNAL
| ==31465==ERROR: ThreadSanitizer: stack-overflow on address 0x7ffee73fffd8 (pc 0x00010807fd2a bp 0x7ffee7400050 sp 0x7ffee73fffb0 T93815)
| #0 __tsan::MetaMap::GetSync(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool) tsan_sync.cpp:195 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x78d2a)
| #1 __tsan::MutexPreLock(__tsan::ThreadState*, unsigned long, unsigned long, unsigned int) tsan_rtl_mutex.cpp:143 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x6cefc)
| #2 wrap_pthread_mutex_lock sanitizer_common_interceptors.inc:4240 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x3dae0)
| #3 flockfile <null>:2 (libsystem_c.dylib:x86_64+0x38a69)
| #4 puts <null>:2 (libsystem_c.dylib:x86_64+0x3f69b)
| #5 wrap_puts sanitizer_common_interceptors.inc (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x34d83)
| #6 __tsan::OnPotentiallyBlockingRegionBegin() cxa_guard_acquire.cpp:8 (foo:x86_64+0x100000e48)
| #7 wrap_pthread_once tsan_interceptors_posix.cpp:1512 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2f6e6)
From the stack trace it can be seen that the caller is unknown, and the
resulting stack-overflow seems to indicate that whoever the caller is
does not have enough stack space or otherwise is running in a limited
environment not yet ready for full instrumentation.
Fix it by reverting behaviour on Mac OS X to not call BlockingRegion
hooks from pthread_once().
Reported-by: azharudd
Reviewed By: glider
Differential Revision: https://reviews.llvm.org/D108305
The shadow for a short granule is stored in the last byte of the
granule. Currently, if there's a tail-overwrite report (a
buffer-overflow-write in uninstrumented code), we report the shadow byte
as a mismatch against the magic.
Fix this bug by slapping the shadow into the expected value. This also
makes sure that if the uninstrumented WRITE does clobber the shadow
byte, it reports the shadow was actually clobbered as well.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D107938
D104556 change the CountersPtr to be relative, however, it did not
update the pointer initialization in __llvm_profile_register_function,
so the platform (eg:AIX) that use __llvm_profile_register_function is now totaly
broken, any PGO code will SEGV.
This patch update the code to reflect that the Data->CountersPtr is now
relative.
Reviewed By: MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D108304
According to comments at https://reviews.llvm.org/D107911,
Trace.MemoryAccessSize fails on Mac buildbots.
Because this test is newly introduced, and is the only user of the code
added in that patch, disable the test on Mac till the problem is
resolved.
Differential Revision: https://reviews.llvm.org/D108294
This change adds support to ORCv2 and the Orc runtime library for static
initializers, C++ static destructors, and exception handler registration for
ELF-based platforms, at present Linux and FreeBSD on x86_64. It is based on the
MachO platform and runtime support introduced in bb5f97e3ad.
Patch by Peter Housel. Thanks very much Peter!
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D108081
Before this change we were locking the StackDepot in the fork()
interceptor. This results in a deadlock when allocator functions are
used in a pthread_atfork() callback.
Instead, set up a pthread_atfork() callback at init that locks/unlocks
both StackDepot and the allocator. Since our callback is set up very
early, the pre-fork callback is executed late, and both post-fork ones
are executed early, which works perfect for us.
Differential Revision: https://reviews.llvm.org/D108063
Vitaly Buka
gtt1995