When trying to debug some `compiler-rt` unittests, I initially had a hard
time because
- even in a `Debug` build one needs to set `COMPILER_RT_DEBUG` to get
debugging info for some of the code and
- even so the unittests used a hardcoded `-O2` which often makes debugging
impossible.
This patch addresses this by instead using `-O0` if `COMPILER_RT_DEBUG`.
Two tests in `sanitizer_type_traits_test.cpp` need to be disabled since
they have undefined references to `__sanitizer::integral_constant<bool,
true>::value`.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91620
It casued some runtimes builds to fail with cmake error
No target "libcxx-abi-static"
see code review.
> When in-tree libcxx is selected as the sanitizer C++ ABI, use
> libcxx-abi-* targets rather than libcxxabi and libunwind directly.
>
> Differential Revision: https://reviews.llvm.org/D134855
This reverts commit 414f9b7d2f.
When in-tree libcxx is selected as the sanitizer C++ ABI, use
libcxx-abi-* targets rather than libcxxabi and libunwind directly.
Differential Revision: https://reviews.llvm.org/D134855
We set in_blocking_func around some blocking C functions so that we don't
delay signal infinitely (if in_blocking_func is set we deliver signals
synchronously).
However, pthread_join is blocking but also call munmap/free to free thread
resources. If we are inside the munmap/free interceptors called from
pthread_join and deliver a signal synchronously, it can lead to deadlocks
and crashes since we re-enter runtime and try to lock the same mutexes
or use the same per-thread data structures.
If we re-enter runtime via an interceptor when in_blocking_func is set,
temporary reset in_blocking_func around the interceptor and restore it back
when we return from the recursive interceptor.
Also move in_blocking_func from ThreadSignalContext to ThreadContext
so that we can CHECK that it's not set in SlotLocker ctor.
Fixes https://github.com/google/sanitizers/issues/1540
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D127845
When upstream `compiler-rt` was recently imported into GCC's
`libsanitizer`, Solaris 11.3 bootstrap broke because in 11.3
`<sys/procfs.h>` doesn't mix with largefile compilation. I'd caused this
in D129837 <https://reviews.llvm.org/D129837> where I forgot that the code
still needs to support Solaris 11.3.
Fixed by restoring the `#undef _FILE_OFFSET_BITS`.
Tested on `sparc-sun-solaris2.11` and `amd64-pc-solaris2.11` (Solaris 11.4)
in LLVM and both Solaris 11.3 and 11.4 in GCC.
Differential Revision: https://reviews.llvm.org/D133556
This patch fixes a test failure on Apple caused by changing standard to c++17.
sanitizer_allocator_test.cpp requires language features introducied in 10.13 for c++17.
After initial investigation, it was not clear how to add this flag to a single file:
https://reviews.llvm.org/D133878
Becuase of this, we have upped the min version of this test suite to 10.13, the min version necessary to support necessary language features.
We felt this was a better option than upping the min version of the product to support a single test.
We are raising deployment target for a single test suite, rather than the product.
Differential Revision: https://reviews.llvm.org/D134091
rdar://98737270
Serialized calls to void-wrapper-functions should have zero bytes of argument
data, but accessing ArgData[0] may (and will, in the case of SmallVector) fail
if the argument data buffer is empty.
This commit fixes the issue by adding a check for empty argument buffers.
If we want to be able to close and then re-open a library then we need to reset
the data section states when the library is closed. This commit updates
MachOPlatform and the ORC runtime to track __data and __common sections, and
reset the state in MachOPlatformRuntimeState::dlcloseDeinitialize.
This is only a first step to full support -- there are other data sections that
we're not capturing, and we'll probably want a more efficient representation
for the sections (rather than passing their string name over IPC), but this is
a reasonable first step.
This commit also contains a fix to MapperJITLinkMemoryManager that prevents it
from calling OnDeallocated twice in the case of an error.
Unlike ExecutorAddr, there's limited value to having a distinct type for
ExecutorAddrDiff, and it's occasionally awkward to work with. The corresponding
LLVM type (llvm::orc::ExecutorAddrDiff) was already made a type-alias in
9e2cfb061a.
libdispatch uses its own heap (_dispatch_main_heap) for some allocations, including the dispatch_continuation_t that holds a dispatch source's event handler.
Objective-C block trampolines (creating methods at runtime with a block as the implementations) use the VM_MEMORY_FOUNDATION region (see 8701d5672d/runtime/objc-block-trampolines.mm (L371)).
This change scans both regions to fix false positives. See tests for details; unfortunately I was unable to reduce the trampoline example with imp_implementationWithBlock on a new class, so I'm resorting to something close to the bug as seen in the wild.
Differential Revision: https://reviews.llvm.org/D129385
The ORC runtime isn't used by clang -- the prefix was just cargo-culted with
the rest of the XRay config when the ORC runtime was introduced. We now want to
make parts of it available for clients to link directly, so this seems like a
good time to fix the name.
Supports dynamic VC runtime. It implements atexits handling which is required to load msvcrt.lib successfully. (the object file containing atexit symbol somehow resolves to static vc runtim symbols) It also default to dynamic vc runtime which tends to be more robust.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D132525
After https://reviews.llvm.org/rG463aa814182a23 tsan replaces llvm
intrinsics with calls to glibc functions. However this approach is
fragile, as slight changes in pipeline can return llvm intrinsics back.
In particular InstCombine can do that.
Msan/Asan already declare own version of these memory
functions for the similar purpose.
KCSAN, or anything that uses something else than compiler-rt, needs to
implement this callbacks.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D133268
After https://reviews.llvm.org/rG463aa814182a23 tsan replaces llvm
intrinsics with calls to glibc functions. However this approach is
fragile, as slight changes in pipeline can return llvm intrinsics back.
In particular InstCombine can do that.
Msan/Asan already declare own version of these memory
functions for the similar purpose.
KCSAN, or anything that uses something else than compiler-rt, needs to
implement this callbacks.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D133268
This implements a FIXME in the runtime library and adds printing the
address at the end of the message as "by 0x123abc". The buffer for the
message is allocated on the stack in a handler, so the stack memory
consumption is slightly increased. No additional external dependencies
are added.
Differential revision: https://reviews.llvm.org/D131914
We want to move functionality from the LLVM ORCTargetProcess library into the
ORC runtime, and this will mean implementing remote-executor testing tools
(like llvm-jitlink-executor and lli-child-target) in the ORC runtime.
This patch refactors the ORC runtime build system to introduce an
add_orc_tool function that can be used to add new test tools. The code is
modeled on existing functions for adding unit tests.
A placeholder orc-rt-executor tool and test are added to verify that the
config changes behave as expected.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D133084
Detailed motivation here: https://docs.google.com/document/d/1xUNo5ovPKJMYxitiHUQVRxGI3iUmspI51Jm4w8puMwo
check-asan (with LSAN enabled) and check-lsan are currently broken on recent macOS versions, due to pervasive false positives. Whenever the Objective-C runtime realizes a class, it allocates data for it, then stores that data with flags in the low bits. This means LSAN can not recognize it as a pointer while scanning.
This change checks every potential pointer on Apple platforms, and if the high bit is set, attempts to extract a pointer by masking out the high bit and flags. This is ugly, but it's also the best approach I could think of (see doc above); very open to other suggestions.
Differential Revision: https://reviews.llvm.org/D133126
When we use selective instrumentation and instrument a file
that is not in the selected files list provided via -fprofile-list,
we generate an empty raw profile. This leads to empty_raw_profile
error when we try to read that profile. This patch fixes the issue by
generating a raw profile that contains only a profile header when
there are no counters and profile data.
A small reproducer for the above issue:
echo "src:other.cc" > code.list
clang++ -O2 -fprofile-instr-generate -fcoverage-mapping
-fprofile-list=code.list code.cc -o code
./code
llvm-profdata show default.profraw
Differential Revision: https://reviews.llvm.org/D132094
The wrap/unwrap operations are applied to pointers after/before conversion to/from
raw addresses. They can be used to tag, untag, sign, or strip signing from
pointers. They currently default to 'rawPtr' (identity) on all platforms, but it
is expected that the default will be set based on the host architecture, e.g.
they would default to signing/stripping for arm64e.
This is the ORC runtime counterpart to f14cb494a34:
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
This reapplies the patch that was reverted in caaafe4ae2 because it
broke Fuchsia builders.
I reverted the changes I made to InstrProfData.inc and instead renamed
the variables in InstrProfilingWriter.c. Also fixed a bug in function
add_security_warnings that was causing it to pass -Wformat-nonliteral
when the compiler doesn't support it.
Alex Brachet