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
I noticed that `test/asan/Unit/lit.site.cfg.py.in` contains two typos,
using the FreeBSD forms of the `LD_*LIBRARY_PATH*` variables on Solaris.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D132736
Fixes this test compile error:
```
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:54:7: error: no matching function for call to '__tsan_get_alloc_stack'
__tsan_get_alloc_stack(mem, trace, num_frames, &thread_id, &thread_os_id);
^~~~~~~~~~~~~~~~~~~~~~
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:17:16: note: candidate function not viable: no known conversion from 'uint64_t **' (aka 'unsigned long long **') to 'uint64_t *' (aka 'unsigned long long *') for 5th argument; remove &
extern "C" int __tsan_get_alloc_stack(void *addr, void **trace, size_t size,
^
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:61:46: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t *' (aka 'unsigned long long *') [-Wformat]
fprintf(stderr, "thread os id = 0x%llx\n", thread_os_id);
~~~~ ^~~~~~~~~~~~
1 warning and 1 error generated.
```
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
The existing code resulted in the max size and access counts being equal
to the min. Compute the max instead (max lifetime was already correct).
Differential Revision: https://reviews.llvm.org/D132515
Michał Górny