Bump asan/tsan versions for upstream commits:
commit f1bb30a4956f83e46406d6082e5d376ce65391e0
Author: Vitaly Buka <vitalybuka@google.com>
Date: Thu Aug 26 10:25:09 2021 -0700
[sanitizer] No THREADLOCAL in qsort and bsearch
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
commit d77b476c1953bcb0a608b2d6a4f2dd9fe0b43967
Author: Dmitry Vyukov <dvyukov@google.com>
Date: Mon Aug 2 16:52:53 2021 +0200
tsan: avoid extra call indirection in unaligned access functions
Currently unaligned access functions are defined in tsan_interface.cpp
and do a real call to MemoryAccess. This means we have a real call
and no read/write constant propagation.
Unaligned memory access can be quite hot for some programs
(observed on some compression algorithms with ~90% of unaligned accesses).
Move them to tsan_interface_inl.h to avoid the additional call
and enable constant propagation.
Also reorder the actual store and memory access handling for
__sanitizer_unaligned_store callbacks to enable tail calling
in MemoryAccess.
Depends on D107282.
Reviewed By: vitalybuka, melver
commit 97795be22f634667ce7a022398c59ccc9f7440eb
Author: Dmitry Vyukov <dvyukov@google.com>
Date: Fri Jul 30 08:35:11 2021 +0200
tsan: optimize test-only barrier
The updated lots_of_threads.c test with 300 threads
started running for too long on machines with low
hardware parallelism (e.g. taskset -c 0-1).
On lots of CPUs it finishes in ~2 secs. But with
taskset -c 0-1 it runs for hundreds of seconds
effectively spinning in the barrier in the sleep loop.
We now have the handy futex API in sanitizer_common.
Use it instead of the passive spin loop.
It makes the test run only faster with taskset -c 0-1,
it runs for ~1.5 secs, while with full parallelism
it still runs for ~2 secs (but consumes less CPU time).
Depends on D107131.
Reviewed By: vitalybuka
tsan in some cases starts ignoring interceptors and only calls the
intercepted functions. But for realpath the behavior for NULL second argument
was only handled in the interceptor and intercepted function was the one
found by dlsym which is often one that doesn't handle NULL as second argument.
Fixed by using dlvsym with "GLIBC_2.3" if possible for intercepted function
and don't emulate behavior in the wrapper.
2021-08-11 Jakub Jelinek <jakub@redhat.com>
* sanitizer_common/sanitizer_common_interceptors.inc: Cherry-pick
llvm-project revision faef0d042f523357fe5590e7cb6a8391cf0351a8.
Appending to a string variable with `+=' is a bashism and does not work in
strict POSIX shells like dash. This results in the extra compilation flags not
to be set correctly. This patch replaces the `+=' syntax with a simple string
interpolation to append to the `EXTRA_CXXFLAGS' variable.
libsanitizer/ChangeLog
PR sanitizer/101111
* configure.tgt: Fix bashism in setting of `EXTRA_CXXFLAGS'.
Bump asan/tsan versions for the upstream commit:
commit acf0a6428681dccac803984bfbb1e3e54248f090
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: Fri Jul 2 02:42:38 2021 +0200
[sanitizer] Fix __sanitizer_kernel_sigset_t endianness issue
setuid(0) hangs on SystemZ under TSan because TSan's BackgroundThread
ignores SIGSETXID. This in turn happens because internal_sigdelset()
messes up the mask bits on big-endian system due to how
__sanitizer_kernel_sigset_t is defined.
Commit d9a1a53b8d80 ("[ESan] [MIPS] Fix workingset-signal-posix.cpp on
MIPS") fixed this for MIPS by adjusting the __sanitizer_kernel_sigset_t
definition. Generalize this by defining __SANITIZER_KERNEL_NSIG based
on kernel's _NSIG and using uptr[] for __sanitizer_kernel_sigset_t.sig
on all platforms.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D105629
which changed __sanitizer_kernel_sigset_t and changed the ABI for function
void __sanitizer_syscall_post_impl_rt_sigaction
(long int, long int,
const __sanitizer::__sanitizer_kernel_sigaction_t*,
__sanitizer::__sanitizer_kernel_sigaction_t*,
SIZE_T);
* asan/libtool-version: Bump version.
* tsan/libtool-version: Likewise.
The Linux kernel has removed the interface to cyclades from
the latest kernel headers[1] due to them being orphaned for the
past 13 years.
libsanitizer uses this header when compiling against glibc, but
glibcs itself doesn't seem to have any references to cyclades.
Further more it seems that the driver is broken in the kernel and
the firmware doesn't seem to be available anymore.
As such since this is breaking the build of libsanitizer (and so the
GCC bootstrap[2]) I propose to remove this.
[1] https://lkml.org/lkml/2021/3/2/153
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379
(cherry picked from commit f7c5351552387bd43f6ca3631016d7f0dfe0f135)
libsanitizer/ChangeLog:
PR sanitizer/100379
* sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry-pick
llvm-project revision f7c5351552387bd43f6ca3631016d7f0dfe0f135.
* sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise.
* sanitizer_common/sanitizer_platform_limits_posix.h: Likewise.
This adds the local patch to handle missing __builtin_os_log_format
on Darwin.
libsanitizer/ChangeLog:
* LOCAL_PATCHES: Add Darwin patch for __builtin_os_log_format.
GCC does not, currently, define __builtin_os_log_format, which
is needed by os/log.h. Do not include that header unless the
builtin is defined (since the header errors out on the same
condition). Provide a work-around solution to the missing API
provided via the header.
libsanitizer/ChangeLog:
* sanitizer_common/sanitizer_mac.cpp : Check for the
availability of __builtin_os_log_format before trying to
include a header depending on it.
(OS_LOG_DEFAULT): New.
(os_log_error): Define to a fall-back using an older API.
As mentioned in the PR, SIGSTKSZ is no longer a compile time constant in
glibc 2.34 and later, so
static const uptr kAltStackSize = SIGSTKSZ * 4;
needs dynamic initialization, but is used by a function called indirectly
from .preinit_array and therefore before the variable is constructed.
This results in using 0 size instead and all asan instrumented programs
die with:
==91==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22)
Here is a cherry-pick from upstream to fix this.
2021-04-17 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/100114
* sanitizer_common/sanitizer_posix_libcdep.cpp: Cherry-pick
llvm-project revisions 82150606fb11d28813ae6da1101f5bda638165fe
and b93629dd335ffee2fc4b9b619bf86c3f9e6b0023.
/home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.cpp:77:25: runtime error: left shift of 0x0000000000000000fffffffffffffffb by 96 places cannot be represented in type '__int128'
#0 0x7ffff754edfe in __ubsan::Value::getSIntValue() const /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.cpp:77
#1 0x7ffff7548719 in __ubsan::Value::isNegative() const /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_value.h:190
#2 0x7ffff7542a34 in handleShiftOutOfBoundsImpl /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_handlers.cpp:338
#3 0x7ffff75431b7 in __ubsan_handle_shift_out_of_bounds /home/marxin/Programming/gcc2/libsanitizer/ubsan/ubsan_handlers.cpp:370
#4 0x40067f in main (/home/marxin/Programming/testcases/a.out+0x40067f)
#5 0x7ffff72c8b24 in __libc_start_main (/lib64/libc.so.6+0x27b24)
#6 0x4005bd in _start (/home/marxin/Programming/testcases/a.out+0x4005bd)
Differential Revision: https://reviews.llvm.org/D97263
Cherry-pick from 16ede0956cb1f4b692dfa619ccfa6ab1de28e19b.
The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.
We take this opportunity to sort out the shared undefined symbols state
rather than propagating the current unsound behaviour into a new rev.
This change means that we default to the case that missing symbols are
considered an error, and if one wants to allow this intentionally, the
confiuration for that case should be set appropriately.
Three existing cases need undefined dynamic lookup:
libitm, where there is already a configuration mechanism to add the
flags.
libcc1, where we add simple configuration to add the flags for Darwin.
libsanitizer, where we can add to the existing extra flags.
libcc1/ChangeLog:
PR target/97865
* Makefile.am: Add dynamic_lookup to LD flags for Darwin.
* configure.ac: Test for Darwin host and set a flag.
* Makefile.in: Regenerate.
* configure: Regenerate.
libitm/ChangeLog:
PR target/97865
* configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.
* configure: Regenerate.
libsanitizer/ChangeLog:
PR target/97865
* configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
Darwin.
* configure: Regenerate.
ChangeLog:
PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.
gcc/ChangeLog:
PR target/97865
* configure: Regenerate.
libatomic/ChangeLog:
PR target/97865
* configure: Regenerate.
libbacktrace/ChangeLog:
PR target/97865
* configure: Regenerate.
libffi/ChangeLog:
PR target/97865
* configure: Regenerate.
libgfortran/ChangeLog:
PR target/97865
* configure: Regenerate.
libgomp/ChangeLog:
PR target/97865
* configure: Regenerate.
libhsail-rt/ChangeLog:
PR target/97865
* configure: Regenerate.
libobjc/ChangeLog:
PR target/97865
* configure: Regenerate.
libphobos/ChangeLog:
PR target/97865
* configure: Regenerate.
libquadmath/ChangeLog:
PR target/97865
* configure: Regenerate.
libssp/ChangeLog:
PR target/97865
* configure: Regenerate.
libstdc++-v3/ChangeLog:
PR target/97865
* configure: Regenerate.
libvtv/ChangeLog:
PR target/97865
* configure: Regenerate.
zlib/ChangeLog:
PR target/97865
* configure: Regenerate.
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
Ensure we build for AArch64 but not for AArch64 ilp32.
libsanitizer/ChangeLog:
* Makefile.am: Condition Build hwasan directory.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Set HWASAN_SUPPORTED based on target
architecture.
* configure.tgt: Likewise.
This patch tries to tie libhwasan into the GCC build system in the same way
that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefile.in: Build libhwasan.
* configure: Build libhwasan.
* configure.ac: Build libhwasan.
* hwasan/Makefile.am: New file.
* hwasan/Makefile.in: New file.
* hwasan/libtool-version: New file.
* interception/Makefile.in: Build libhwasan.
* libbacktrace/Makefile.in: Build libhwasan.
* libsanitizer.spec.in: Build libhwasan.
* lsan/Makefile.in: Build libhwasan.
* sanitizer_common/Makefile.in: Build libhwasan.
* tsan/Makefile.in: Build libhwasan.
* ubsan/Makefile.in: Build libhwasan.
In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address. `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.
This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.
This occurs when `GetModuleNameAndOffsetForPC` succeeds for some address
not in a dynamically loaded library. One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.
Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
Differential Revision: https://reviews.llvm.org/D91344
