Summary:
This change adds support for the setjmp(3)/longjmp(3)
family of functions on NetBSD.
There are three types of them on NetBSD:
- setjmp(3) / longjmp(3)
- sigsetjmp(3) / sigsetjmp(3)
- _setjmp(3) / _longjmp(3)
Due to historical and compat reasons the symbol
names are mangled:
- setjmp -> __setjmp14
- longjmp -> __longjmp14
- sigsetjmp -> __sigsetjmp14
- siglongjmp -> __siglongjmp14
- _setjmp -> _setjmp
- _longjmp -> _longjmp
This leads to symbol renaming in the existing codebase.
There is no such symbol as __sigsetjmp/__longsetjmp
on NetBSD
Add a comment that GNU-style executable stack
note is not needed on NetBSD. The stack is not
executable without it.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40337
llvm-svn: 319189
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the thread sanitizer to not work properly. This
patch adds support for 47 bit VMA kernels for powerpc64.
(second part)
Tested on several 4.x and 3.x kernel releases.
llvm-svn: 319180
This change is the first in a series of changes to get the XRay runtime
building on macOS. This first allows us to build the minimal parts of
XRay to get us started on supporting macOS development. These include:
- CMake changes to allow targeting x86_64 initially.
- Allowing for building the initialisation routines without
`.preinit_array` support.
- Use __sanitizer::SleepForMillis() to work around the lack of
clock_nanosleep on macOS.
- Deprecate the xray_fdr_log_grace_period_us flag, and introduce
the xray_fdr_log_grace_period_ms flag instead, to use
milliseconds across platforms.
Reviewers: kubamracek
Subscribers: llvm-commits, krytarowski, nglevin, mgorny
Differential Review: https://reviews.llvm.org/D39114
llvm-svn: 319165
The proper index is 6, not 2.
Patch extracted from https://reviews.llvm.org/D40337
Reviewed and accepted by <dvyukov>.
Sponsored by <The NetBSD Foundation>
llvm-svn: 319163
Summary:
NetBSD uses the __sigaction14 symbol name for historical and compat
reasons for the sigaction(2) function name.
Rename the interceptors and users of sigaction to sigaction_symname
and reuse it in the code base.
This change fixes 4 failing tests in TSan/NetBSD:
- ThreadSanitizer-x86_64 :: signal_errno.cc
- ThreadSanitizer-x86_64 :: signal_malloc.cc
- ThreadSanitizer-x86_64 :: signal_sync2.cc
- ThreadSanitizer-x86_64 :: signal_thread.cc
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis, dvyukov, kcc
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40341
llvm-svn: 319160
"offset" declared in a macro may shadow a variable with the same name
in the caller which is used in a macro argument. We are quite lucky
that it does not actually happen, but rename the variable anyway to
be on the safe side.
llvm-svn: 319115
Summary:
Bionic doesn't initialize its globals early enough. This causes issues when
trying to access them from a preinit_array (b/25751302) or from another
constructor called before the libc one (b/68046352). __progname is initialized
after the other globals, so we can check its value to know if calling
`getauxval` is safe.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D40504
llvm-svn: 319099
Summary:
Now that the sanitizer_common interface for MmapNoAccess / MmapFixed
have been refactored to allow a more OO-esque access pattern, update the
Fuchsia mmap implementation to take advantage of this.
Previously MmapNoAccess / MmapFixed relied on a global allocator_vmar,
since the sanitizer_allocator only called MmapNoAccess once. Now, we
create a new VMAR per ReservedAddressRange object.
This allows the sanitizer allocator to work in tandem with the Scudo
secondary allocator.
This is part 4 of a 4 part changeset:
* part 1 https://reviews.llvm.org/D38593
* part 2 https://reviews.llvm.org/D38592
* part 3 https://reviews.llvm.org/D38593
Reviewers: mcgrathr, cryptoad
Reviewed By: cryptoad
Subscribers: alekseyshl, mcgrathr, kubamracek, mehdi_amini
Differential Revision: https://reviews.llvm.org/D38595
llvm-svn: 319083
Summary:
Add atomic verification to ensure that Thread is Joined after marking it
Finished.
It is required for NetBSD in order to prevent Thread Exited/Joined race,
that may occur when native system libpthread(3) cannot be reliably traced
in a way to guarantee that the mentioned events happen one after another.
This change fixes at least TSan and LSan on NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40294
llvm-svn: 319004
Summary:
Stop using the Linux solution with pthread_key_create(3).
This approach does not work on NetBSD, because calling
the thread destructor is not the latest operation on a POSIX
thread entity.
Detect _lwp_exit(2) call as it is really the latest operation
called from a detaching POSIX thread.
The pthread_key_create(3) solution also cannot be used
in early libc/libpthread initialization on NetBSD as the
system libraries are not bootstrapped enough.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, dvyukov
Reviewed By: dvyukov
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40457
llvm-svn: 318994
Summary:
InitializeSwiftDemangler() attempts to resolve the
swift_demangle symbol. If this is not available, we
observe dlerror message leak.
Caught on NetBSD/amd64 in TSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kubamracek, vitalybuka, dvyukov, eugenis
Reviewed By: dvyukov
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40382
llvm-svn: 318980
Summary:
This patch aims at condensing the hardware CRC32 feature detection and making
it slightly more effective on Android.
The following changes are included:
- remove the `CPUFeature` enum, and get rid of one level of nesting of
functions: we only used CRC32, so we just implement and use
`hasHardwareCRC32`;
- allow for a weak `getauxval`: the Android toolchain is compiled at API level
14 for Android ARM, meaning no `getauxval` at compile time, yet we will run
on API level 27+ devices. The `/proc/self/auxv` fallback can work but is
worthless for a process like `init` where the proc filesystem doesn't exist
yet. If a weak `getauxval` doesn't exist, then fallback.
- couple of extra corrections.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, aemerson, srhines, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D40322
llvm-svn: 318859
Summary:
This change allows Fuchsia to boot properly using the Scudo allocator.
A first version of this commit was reverted by rL317834 because it broke Android
builds for toolchains generated with older NDKs. This commit introduces a
fall back to solve that issue.
Reviewers: cryptoad, krytarowski, rnk, alekseyshl
Reviewed By: cryptoad, krytarowski, alekseyshl
Subscribers: llvm-commits, srhines, kubamracek, krytarowski
Differential Revision: https://reviews.llvm.org/D40121
llvm-svn: 318802
Summary:
Android for API level >= 21 has `getauxval`. Enable `SANITIZER_USE_GETAUXVAL`
when those requirements are met. Correct a typo in the header.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D40260
llvm-svn: 318775
Summary:
The pthread_once(3)/NetBSD type is built with the following structure:
struct __pthread_once_st {
pthread_mutex_t pto_mutex;
int pto_done;
};
Set the pto_done position as shifted by __sanitizer::pthread_mutex_t_sz
from the beginning of the pthread_once struct.
This corrects deadlocks when the pthread_once(3) function
is used.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40262
llvm-svn: 318742
Summary:
Before this patch, XRay's basic (naive mode) logging would be
initialised and installed in an adhoc manner. This patch ports the
implementation of the basic (naive mode) logging implementation to use
the common XRay framework.
We also make the following changes to reduce the variance between the
usage model of basic mode from FDR (flight data recorder) mode:
- Allow programmatic control of the size of the buffers dedicated to
per-thread records. This removes some hard-coded constants and turns
them into runtime-controllable flags and through an Options
structure.
- Default the `xray_naive_log` option to false. For now, the only way
to start basic mode is to set the environment variable, or set the
default at build-time compiler options. Because of this change we've
had to update a couple of tests relying on basic mode being always
on.
- Removed the reliance on a non-trivially destructible per-thread
resource manager. We use a similar trick done in D39526 to use
pthread_key_create() and pthread_setspecific() to ensure that the
per-thread cleanup handling is performed at thread-exit time.
We also radically simplify the code structure for basic mode, to move
most of the implementation in the `__xray` namespace.
Reviewers: pelikan, eizan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40164
llvm-svn: 318734
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
ASan requires that the min alignment be at least the shadow
granularity, so add an init function to do that.
Differential Revision: https://reviews.llvm.org/D39473
llvm-svn: 318717
Summary:
Correct handling of libpthread(3) functions in TSan/NetBSD:
- pthread_cond_init(3),
- pthread_cond_signal(3),
- pthread_cond_broadcast(3),
- pthread_cond_wait(3),
- pthread_cond_destroy(3),
- pthread_mutex_init(3),
- pthread_mutex_destroy(3),
- pthread_mutex_trylock(3),
- pthread_rwlock_init(3),
- pthread_rwlock_destroy(3),
- pthread_rwlock_rdlock(3),
- pthread_rwlock_tryrdlock(3),
- pthread_rwlock_wrlock(3),
- pthread_rwlock_trywrlock(3),
- pthread_rwlock_unlock(3),
- pthread_once(3).
Code out of the libpthread(3) context uses the libc symbols
that are prefixed with __libc_, for example: __libc_cond_init.
This caused that these functions were invisible to sanitizers on NetBSD.
Intercept the libc-specific ones and add them as NetBSD-specific aliases
for the common pthread(3) ones.
NetBSD needs to intercept both functions, as the regularly named ones
are used internally in libpthread(3).
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40243
llvm-svn: 318673
Summary:
NetBSD uses indirection for old threading functions for historical reasons
The mangled names are internal implementation detail and should not be
exposed even in backtraces.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, dvyukov
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40251
llvm-svn: 318671
Summary:
This change reverts r318575 and changes FindDynamicShadowStart() to
keep the memory range it found mapped PROT_NONE to make sure it is
not reused. We also skip MemoryRangeIsAvailable() check, because it
is (a) unnecessary, and (b) would fail anyway.
Reviewers: pcc, vitalybuka, kcc
Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D40203
llvm-svn: 318666
Summary:
This is a second attempt after D40100 induced racey crashes with ASan
(due to `__android_log_write` and the `strncpy` interceptor on API >= 21).
This new version checks the runtime API level to be <= `ANDROID_KITKAT` for
the use of `__android_log_write`, otherwise we use `syslog`, which should
conform with the previous behavior.
Unfortunately despite numerous efforts I couldn't reproduce the original
crashes in my environments so I couldn't test that the fix was actually
preventing crashes.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, srhines, kubamracek
Differential Revision: https://reviews.llvm.org/D40149
llvm-svn: 318659
The __libc_mutex_lock, __libc_mutex_unlock and __libc_thr_setcancelstate
functions return int, not void.
This does not seem to introduce a functional change, however it looks
better with fixed the function prototype.
Sponsored by <The NetBSD Foundation>
llvm-svn: 318654
Summary:
Correct handling of three libpthread(3) functions on NetBSD:
- pthread_mutex_lock(3),
- pthread_mutex_unlock(3),
- pthread_setcancelstate(3).
Code out of the libpthread(3) context uses the libc symbols:
- __libc_mutex_lock,
- __libc_mutex_unlock,
- __libc_thr_setcancelstate.
The threading library (libpthread(3)) defines strong aliases:
- __strong_alias(__libc_mutex_lock,pthread_mutex_lock)
- __strong_alias(__libc_mutex_unlock,pthread_mutex_unlock)
- __strong_alias(__libc_thr_setcancelstate,pthread_setcancelstate)
This caused that these functions were invisible to sanitizers on NetBSD.
Intercept the libc-specific ones and add them as NetBSD-specific aliases
for the common pthread(3) ones.
NetBSD needs to intercept both functions, as the regularly named ones
are used internally in libpthread(3).
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40241
llvm-svn: 318646
Revert the following commits:
r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22.
r318235 [asan] Prevent rematerialization of &__asan_shadow.
r317948 [sanitizer] Remove unnecessary attribute hidden.
r317943 [asan] Use dynamic shadow on 32-bit Android.
MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer
that may overlap with the address range that we plan to use for the
dynamic shadow mapping. This is causing random startup crashes.
llvm-svn: 318575
Rather than assertion failing, we can fall back to the
non-optimized version which works for any shadow scale.
Differential Revision: https://reviews.llvm.org/D39474
llvm-svn: 318460
Summary:
The patch seems to have turned some Android tests flaky. The reason is unclear.
This reverts D40100 in case we can't figure out what is happening.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: srhines, kubamracek
Differential Revision: https://reviews.llvm.org/D40138
llvm-svn: 318438
The requirement is that shadow memory must be aligned to page
boundaries (4k in this case). Use a closed form equation that always
satisfies this requirement.
Differential Revision: https://reviews.llvm.org/D39471
llvm-svn: 318421
Summary:
Recent Bionic have a slew of `async_safe_*` logging functions that are
basically the liblog ones but included within the libc. They have the advantage
of not allocating memory. `async_safe_write_log` does no formatting and is
likely the best candidate for logging.
Use a weak definition to try and use it. Also, avoid API level checks (as
the toolchain is compiled at a rather low API level) for `__android_log_write`
in favor of a weak definition as well.
Keep the fallback to `syslog` if nothing else was found.
I tried to overhaul the code block to only have a single #if SANITIZER_ANDROID
but I am not particularly attached to the form. LMKWYT.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D40100
llvm-svn: 318410
Summary:
lsan_preinit.cc is meant to be linked into executable and calls
lsan_init from .preinit_array section. But if liblsan is a shared library,
then this doesn't work, because the symbol is not exported. This patch fixes
that. The counterparts like asan_init or __tsan_init already do have
SANITIZER_INTERFACE_ATTRIBUTE.
Committing on behalf of jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D39889
llvm-svn: 318349
Summary:
For some filesystems, readdir will not populate dirent::d_type with valuable information. This causes libfuzzer to proceed with an empty corpus, instead of the file it contains.
This has been tested on a server using XFS.
It should fix https://bugs.llvm.org//show_bug.cgi?id=25991
Reviewers: kcc
Reviewed By: kcc
Differential Revision: https://reviews.llvm.org/D40028
llvm-svn: 318303
Summary:
This implements an opportunistic check for the RSS limit.
For ASan, this was implemented thanks to a background thread checking the
current RSS vs the set limit every 100ms. This was deemed problematic for Scudo
due to potential Android concerns (Zygote as pointed out by Aleksey) as well as
the general inconvenience of having a permanent background thread.
If a limit (soft or hard) is specified, we will attempt to update the RSS limit
status (exceeded or not) every 100ms. This is done in an opportunistic way: if
we can update it, we do it, if not we return the current status, mostly because
we don't need it to be fully consistent (it's done every 100ms anyway). If the
limit is exceeded `allocate` will act as if OOM for a soft limit, or just die
for a hard limit.
We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for
configuration of the limits.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40038
llvm-svn: 318301
Summary:
This change fixes the XRay trampolines aside from the __xray_CustomEvent
trampoline to align the stack to 16-byte boundaries before calling the
handler. Before this change we've not been explicitly aligning the stack
to 16-byte boundaries, which makes it dangerous when calling handlers
that leave the stack in a state that isn't strictly 16-byte aligned
after calling the handlers.
We add a test that makes sure we can handle these cases appropriately
after the changes, and prevents us from regressing the state moving
forward.
Fixes http://llvm.org/PR35294.
Reviewers: pelikan, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40004
llvm-svn: 318261
Summary:
This is mostly some cleanup and shouldn't affect functionalities.
Reviewing some code for a future addition, I realized that the complexity of
the initialization path was unnecessary, and so was maintaining a structure
for the allocator options throughout the initialization.
So we get rid of that structure, of an extraneous level of nesting for the
`init` function, and correct a couple of related code inaccuracies in the
flags cpp.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39974
llvm-svn: 318157
It is included in the built sources for all other arches supported
for MinGW currently, except for arm.
Differential Revision: https://reviews.llvm.org/D39938
llvm-svn: 318139
Kamil Rytarowski