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.
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
Compiles and moves the original C code for main to Inputs/dlopen-dlclose-x2.S,
where it can be shared with other testcases that want a
dlopen-dlclose-dlopen-dlclose sequence. The assembly containging the
initializers to be tested is moved into the test file.
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.
These four tests are failing on tvOS devices (not simulators) so XFAIL
them for now for CI and investigate further.
rdar://99981102
Differential Revision: https://reviews.llvm.org/D133963
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
Enable -Wsizeof-array-div and -Wsizeof-pointer-divcompiler.
Also, replace -Wmemset-transposed-args with -Wsuspicious-memaccess. The
latter automatically enables the former and a few other warnings.
Differential Revision: https://reviews.llvm.org/D133783
The fuzzer tests cross_over.test and merge-control-file.test are not handled
correctly on ios device testing. On-device testing requires the macros %t, %s,
etc. to be expanded for a different default directory than when testing on host.
rdar://99889376
Differential Revision: https://reviews.llvm.org/D133811
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.
As described in Issue #54196
<https://github.com/llvm/llvm-project/issues/54196>, the ideas of `clang`
and `compiler-rt` where runtime libs are located with
`-DLLVM_ENABLE_RUNTIMES` can differ. This is the `compiler-rt` side of the
patch I've used to get them in sync for the `amd64-pc-solaris2.11` and
`sparc64-unknown-linux-gnu` release builds.
Tested on `amd64-pc-solaris2.11` and `sparc64-unknown-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D133406
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
Reverting a patch that was added to test for getpwnam(NULL) -- it was noted at the time the behavior might have been a bug, however the patch was added for binary compatibility. Because of the change in the expected behavior, we are reverting this commit, as the test added is no longer passing.
Update: Rather than reverting the original commit, updating this to only remove the unnecessary test.
Original Patch: https://reviews.llvm.org/D40052
rdar://98592334
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Depends on D111283
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
Fix the is_binutils_lto_supported() function to handle missing
executables gracefully. Currently, the function does not catch
exceptions from subprocess.Popen() and therefore causes lit to crash
if config.gold_executable does not specify a valid executable:
```
lit: /usr/lib/python3.11/site-packages/lit/TestingConfig.py:136: fatal: unable to parse config file '/tmp/portage/sys-libs/compiler-rt-
15.0.0/work/compiler-rt/test/lit.common.cfg.py', traceback: Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/lit/TestingConfig.py", line 125, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 561, in <module>
if is_binutils_lto_supported():
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 543, in is_binutils_lto_supported
ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, env={'LANG': 'C'})
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/subprocess.py", line 1022, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.11/subprocess.py", line 1899, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'GOLD_EXECUTABLE-NOTFOUND'
```
Differential Revision: https://reviews.llvm.org/D133358
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
Commit 4adc5bead4 moved a dependence on llvm-jitlink from
SANITIZER_COMMON_LIT_TEST_DEPS to ORC_TEST_DEPS, but in doing so it moved it
out from under a 'NOT COMPILER_RT_STANDALONE_BUILD ...' conditional. This led
to failures on standalone builds.
This commit adds the conditional to the ORC_TEST_DEPS assignment to work
around the issue while we look a longer term fix.
rdar://99453446
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
Lang Hames