Similar to 60cc1d3218 for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(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)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
Fixes segfaults on x86_64 caused by instrumented code running before
shadow is set up.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D118171
This fixes the following error:
sanitizer_interface_internal.h:77:7: error: conflicting types for
'__sanitizer_get_module_and_offset_for_pc'
int __sanitizer_get_module_and_offset_for_pc(
common_interface_defs.h:349:5: note: previous declaration is here
int __sanitizer_get_module_and_offset_for_pc(void *pc, char *module_path,
I am getting it on a code that uses sanitizer_common (includes internal headers),
but also transitively gets includes of the public headers in tests
via an internal version of gtest.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D118910
We (Linaro) still have the occasional failure here due
to high load on a shared buildbot machine.
We are looking into general soloutions but perhaps this
will help in the meantime.
Instead of calling asan_report.* directly from assembly code they have been replaced with corresponding asan_report.*_asm function, which call asan_report.*. All asan_report.* are now undefined weak symbols, which allows DSOs to link when z defs is used.
Reviewed By: MaskRay, morehouse
Differential Revision: https://reviews.llvm.org/D118813
I was looking around and noticed that builtins for iossim, tvossim
and watchossim was missing arm64 builds, while apple's clang
toolchain ship with these. After a bit of searching around it just
seems like these are not listed correctly in CMake to be enabled.
I enabled just arm64 since I saw that Apple clang didn't include
arm64e.
Reviewed By: t.p.northover
Differential Revision: https://reviews.llvm.org/D118759
Unfortunately, the `sanitizer_common` tests are disabled on many targets
that are supported by `sanitizer_common`, making it easy to miss issues
with that support. This patch enables SPARC testing.
Beside the enabling proper, the patch fixes (together with D91607
<https://reviews.llvm.org/D91607>) the failures of the `symbolize_pc.cpp`,
`symbolize_pc_demangle.cpp`, and `symbolize_pc_inline.cpp` tests. They
lack calls to `__builtin_extract_return_addr`. When those are added, they
`PASS` when compiled with `gcc`. `clang` incorrectly doesn't implement a
non-default `__builtin_extract_return_addr` on several targets, SPARC
included.
Because `__builtin_extract_return_addr(__builtin_return_addr(0))` is quite
a mouthful and I'm uncertain if the code needs to compile with msvc which
appparently has it's own `_ReturnAddress`, I've introduced
`__sanitizer_return_addr` to hide the difference and complexity. Because
on 32-bit SPARC `__builtin_extract_return_addr` differs when the calling
function returns a struct, I've added a testcase for that.
There are a couple more tests failing on SPARC that I will deal with
separately.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91608
setjmp can return twice, but PostDominatorTree is unaware of this. as
such, it overestimates postdominance, leaving some cases (see attached
compiler-rt) where memory does not get untagged on return. this causes
false positives later in the program execution.
this is a crude workaround to unblock use-after-scope for now, in the
longer term PostDominatorTree should bemade aware of returns_twice
function, as this may cause problems elsewhere.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D118647
These tests appear to be causing timeouts on our silent
Thumbv7 bot: https://lab.llvm.org/staging/#/builders/162/builds/260
It is possible they would complete given enough time. value-profile-switch
seems to take a long time even on a powerful Armv8 machine.
The definition of the MemInfoBlock is shared between the memprof
compiler-rt runtime and llvm/lib/ProfileData/. This change removes the
memprof_meminfoblock header and moves the struct to the shared include
file. To enable this sharing, the Print method is moved to the
memprof_allocator (the only place it is used) and the remaining uses are
updated to refer to the MemInfoBlock defined in the MemProfData.inc
file.
Also a couple of other minor changes which improve usability of the
types in MemProfData.inc.
* Update the PACKED macro to handle commas.
* Add constructors and equality operators.
* Don't initialize the buildid field.
Differential Revision: https://reviews.llvm.org/D116780
`__builtin_c[tl]z` accepts `unsigned int` argument that is not always the
same as uint32_t. For example, `unsigned int` is uint16_t on MSP430.
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D86547
Use s[iu]_int instead of `(unsigned) int` and d[ui]_int instead of
`(unsigned) long long` for LibCall arguments.
Note: the `*vfp` LibCall versions were NOT touched.
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D86546
As discussed in D118021 <https://reviews.llvm.org/D118021>, `clang -m32` on
Solaris/sparcv9 currently incorrectly doesn't inline atomics on 8-byte
operands, unlike `gcc`. With the workaround in that patch in place, we're
left with may undefined references to `__sync_val_compare_and_swap_8`,
which isn't provided by `libatomic`. This reference is due to the use of
`__sync_val_compare_and_swap` in `sanitizer_atomic_clang.h`'s
`atomic_compare_exchange_strong`. As is already done in
`scudo/standalone/atomic_helpers.h`, using `__atomic_compare_exchange`
instead avoids this problem.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D118024
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
In glibc before 2.33, include/sys/stat.h defines fstat/fstat64 to
`__fxstat/__fxstat64` and provides `__fxstat/__fxstat64` in libc_nonshared.a.
The symbols are glibc specific and not needed on other systems.
Reviewed By: vitalybuka, #sanitizers
Differential Revision: https://reviews.llvm.org/D118423
Fixes a false positive that occurs when a user-implemented memmove is
instrumented by HWASan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D118180
Use the llvm flag `-pgo-function-entry-coverage` to create single byte "counters" to track functions coverage. This mode has significantly less size overhead in both code and data because
* We mark a function as "covered" with a store instead of an increment which generally requires fewer assembly instructions
* We use a single byte per function rather than 8 bytes per block
The trade off of course is that this mode only tells you if a function has been covered. This is useful, for example, to detect dead code.
When combined with debug info correlation [0] we are able to create an instrumented Clang binary that is only 150M (the vanilla Clang binary is 143M). That is an overhead of 7M (4.9%) compared to the default instrumentation (without value profiling) which has an overhead of 31M (21.7%).
[0] https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116180
This is a follow up to D118101, that added bexpfull to the test on instrprof-get-filename-merge-mode.c AIX, in order to get the
necessary symbols exported. But unfortunately the extra dependent symbols this exports actually cause segfaults, which is why
this isn't really recommended in the first place, so just use an actual export list.
Differential Revision: https://reviews.llvm.org/D118310
Use the `llvm-profdata show` command to verify debug info for profile correlation using the `--debug-info` option.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D118181
The "asan/asan_mapping.h" header relies on sanitizer_platform.h
macros, but doesn't directly include the header. All the existing
uses until recently happened to be in places where some other header
had indirectly included sanitizer_platform.h first. The addition of
asan_rtl_x86_64.S was the first place to use "asan/asan_mapping.h"
alone. It so happens that its uses of the macros make having no
macros defined equivalent to SANITIZER_LINUX, so this did not affect
Linux builds. But the assembly constants in asan_rtl_x86_64.S were
wrong for Fuchsia when SANITIZER_FUCHSIA was not properly defined.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D118296
When using the in-tree libc++, we should be using the full path to
ensure that we're using the right library and not accidentally pick up
the system library.
Differential Revision: https://reviews.llvm.org/D118200
We have been relying on the logic for C++ ABI library for sanitizer
tests but that's incorrect since most tests require a full C++ library
and not just C++ ABI. This change tries to address this by using the
dependency on libc++ if available.
Differential Revision: https://reviews.llvm.org/D118163
There is no need to compress the names string when correlating with
debug info since InstrProfReader will immediately uncompress it anyway.
This also removes the dependency on zlib in this case.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D118176
The AIX linker doesn't export any symbols by default, so an export list is usually used. Since clang doesn't have the tools to auto-generate an export list yet, just pass the linker an extra opt to tell it to export everything. This is generally not recommended for real shared libs, but is fine for the purpose of this test.
Differential Revision: https://reviews.llvm.org/D118101
`_vfork` moved from libsystem_kernel.dylib to libsystem_c.dylib as part
of the below changes. The iOS simulator does not actually have
libsystem_kernel.dylib of its own, it only has the host Mac's. The
umbrella-nature of Libsystem makes this movement transparent to
everyone; except the simulator! So when we "back deploy", i.e., use the
current version of TSan with an older simulator runtime then this symbol
is now missing, when we run on the latest OS (but an older simulator
runtime).
Note we use `SANITIZER_IOS` because usage of vfork is forbidden on iOS
and the API is completely unavailable on watchOS and tvOS, even if this
problem is specific to the iOS simulator.
Caused by:
rdar://74818691 (Shim vfork() to fork syscall on iOS)
rdar://76762076 (Shim vfork() to fork syscall on macOS)
Radar-Id: rdar://8634734
This reverts commit 8c9f62ea90, which is causing build failures on
the bots because it inadvertently changes the output directory of the compiler-rt libs when
built as a runtime.
Differential Revision: https://reviews.llvm.org/D117815
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.
This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
This gives us the option of using CMake modules from LLVM, and other
things. We will use that to deduplicate code later.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D117815
https://reviews.llvm.org/D116179 introduced some changes to
`InstrProfData.inc` which broke some downstream builds. This commit
reverts those changes since they only changes two field names.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D117631
The kern.elf64.aslr.pie_enable and kern.elf32.aslr.pie_enable sysctls
control the default setting for PIE binary address randomization, but
it is possible to enable or disable ASLR on a per-process basis. So,
use procctl(2) to query whether ASLR is enabled.
(Note that with ASLR enabled but sysctl kern.elf64.aslr.pie_enable=0
a PIE binary will in effect have randomization disabled, and would be
functional with msan. This is not intended as as a user-facing control
though; proccontrol(1) should be used to disable aslr for the process.)
Reviewed By: devnexen
Differential Revision: https://reviews.llvm.org/D117521
1b1c8d changed `enable-noundef-analysis` flag to
`disable-noundef-analysis`. noundef_analysis.cpp was using old
`enable-noundef-analysis` flag and this patch fixes it.
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
089acf2522 updated WrapperFunctionCall to carry arbitrary argument payloads
(rather than plain address ranges). This commit implements the corresponding
update for the ORC runtime.
Fixes:
[2587/4073] Building CXX object projects\compiler-rt\lib\sanitizer_common\CMakeFiles\RTSanitizerCommon.x86_64.dir\sanitizer_stoptheworld_win.cpp.obj
D:\git\llvm-project\compiler-rt\lib\sanitizer_common\sanitizer_stoptheworld_win.cpp(125,33): warning: comparison of integers of different signs: 'DWORD' (aka 'unsigned long') and 'int' [-Wsign-compare]
if (SuspendThread(thread) == -1) {
~~~~~~~~~~~~~~~~~~~~~ ^ ~~
1 warning generated.
Dimitry Andric