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.
Simplify InitializeOsSupport() by separating code for detecting and
enabling the tagged address ABI.
Also drop the unnecessary errno checks (regardless of errno value, we
cannot assume that tagging works if the system call failed) and ensure
prctl(PR_SET_TAGGED_ADDR_CTRL) is only called on Android, not on x86
(where arch_prctl(ARCH_ENABLE_TAGGED_ADDR, kTagBits) is used).
Depends on D132544
Differential Revision: https://reviews.llvm.org/D132545
Use a helper function to print an error message and die in the case
flags()->fail_without_syscall_abi is set.
Because x86 doesn't have `sysctl abi.tagged_addr_disabled`, do not
mention it in the error message for non-Android runtime.
Depends on D132543
Differential Revision: https://reviews.llvm.org/D132544
Move the definitions outside InitializeOsSupport(). Also remove the
undefs, as these constants won't be visible outside the .cpp file anyway.
Differential Revision: https://reviews.llvm.org/D132543
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 0d66dc57e8 because it
broke a few bots.
I made changes so that cmake checks whether some of the flags are
supported by the compiler that is used before adding them to the list.
Also, I moved function add_security_warnings to CompilerRTUtils.cmake so
that it is defined before it's used.
Differential Revision: https://reviews.llvm.org/D131714
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
Differential Revision: https://reviews.llvm.org/D131714