This patch extends the PGO infrastructure with an option to prefer the
instrumentation of loop entry blocks.
This option is a generalization of
19fb5b467b,
and helps to cover cases where the loop exit is never executed.
An example where this can occur are event handling loops.
Note that change does NOT change the default behavior.
At some point FreeBSD introduced libsys as a wrapper between syscalls
and libc, and then linking sanitized programs started failing with:
```text
# c++ -fsanitize=address main.cc
ld: error: undefined symbol: __elf_aux_vector
>>> referenced by sanitizer_linux_libcdep.cpp:950 (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a
c++: error: linker command failed with exit code 1 (use -v to see invocation)
```
Mark `__elf_aux_vector` as weak in the internal sanitizer declaration,
so the linker will accept it at link time. The dynamic linker will then
take care of the symbol at run time.
Since #105495, we will build sanitizer_common when
COMPILER_RT_BUILD_CTX_PROFILE is set. But we have outstanding failures
when building sanitizer_common, so for now we'll disable ctx_profile
too.
I was trying to build compiler-rt with /usr/bin/clang-17 and the testsuite
failed due to the code in lit.common.cfg.py:
```
# GCC-ASan uses dynamic runtime by default (since config.bits is not set).
if config.compiler_id == "GNU":
gcc_dir = os.path.dirname(config.clang)
libasan_dir = os.path.join(gcc_dir, "..", "lib" + config.bits)
push_dynamic_library_lookup_path(config, libasan_dir)
```
Fix this in two ways: First, if the test compiler matches the library
compiler, set COMPILER_RT_TEST_COMPILER_ID to CMAKE_C_COMPILER_ID. Second,
relax the regex detecting clang to allow any kind of suffix.
Reviewed By: compnerd
Pull Request: https://github.com/llvm/llvm-project/pull/117812
We don't need 128-bit integers here, instead rewrite the fp_test.h helpers
to avoid the need for __int128. Also change the high argument for
compareResultF80() and F80FromRep80() to be uint16_t since values greater
than this do not make any sense. This should allow the compiler to detect
accidentally swapping the arguments.
Reviewed By: biabbas, alexander-shaposhnikov
Pull Request: https://github.com/llvm/llvm-project/pull/117818
This is a complex one - `syscall` is used when people want to bypass
libc and make the call directly
However, this call:
* Has a variable amount of arguments (up to 6, typically)
* Has arguments that can be any type, (think of whatever arguments go in
to the libc call, or see more details here
https://syscalls.mebeim.net/?table=x86/64/x64/latest)
I've tried to put in a couple tests to ensure we aren't mucking with the
underlying functionality and they seem to be working.
It appears already some lines above with this comment:
"Cannot overwrite control-instruction. Return 0 to indicate failure.".
Replacing just the comment in the first appearance.
Found after creating the test in #113085.
Similar to `__asan_default_options`, users can specify default options
upon building the instrumented binaries by providing their own
definition of `__xray_default_options` which returns the option strings.
This is useful in cases where setting the `XRAY_OPTIONS` environment
variable might be difficult. Plus, it's a convenient way to populate
XRay options when you always want the instrumentation to be enabled.
It turns out we were not passing -m32 to the check_c_source_compiles()
invocation since CMAKE_REQUIRE_FLAGS needs to be string separated list
and
we were passing a ;-separated CMake list which appears to be parsed by
CMake as 'ignore all arguments beyond the first'.
Fix this by transforming the list to a command line first.
With this change, Clang 17 no longer claims to support _Float16 for
i386.
Using a `--section-start` address in the test was causing link errors on
some targets. Now it uses a linker script to move the note after `.bss`,
which should still have the kind of memory offset we're looking for.
This is a follow-up to #114907 to fix buildbot errors.
This relands #86209 which was reverted because ./bin/llvm no longer
accepted test paths in the source tree instead of the build tree. This was
happening because `add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit`
was called before all tsst suites were registered, and therefore it was
missing the source->build dir mappings.
Original commit message:
I am currently trying to test the LLVM runtimes (including compiler-rt)
against an installed LLVM tree rather than a build tree (since that is
no longer available). Currently, the runtimes build of compiler-rt assumes
that LLVM_BINARY_DIR is writable since it uses configure_file() to write
there during the CMake configure stage. Instead, generate this file inside
CMAKE_CURRENT_BINARY_DIR, which will match LLVM_BINARY_DIR when invoked
from llvm/runtimes/CMakeLists.txt.
I also needed to make a minor change to the hwasan tests: hwasan_symbolize
was previously found in the LLVM_BINARY_DIR, but since it is generated as
part of the compiler-rt build it is now inside the CMake build directory
instead. I fixed this by passing the output directory to lit as
config.compiler_rt_bindir and using llvm_config.add_tool_substitutions().
For testing that we no longer write to the LLVM install directory as
part of testing or configuration, I created a read-only bind mount and
configured the runtimes builds as follows:
```
$ sudo mount --bind --read-only ~/llvm-install /tmp/upstream-llvm-readonly
$ cmake -DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_C_COMPILER=/tmp/upstream-llvm-readonly/bin/clang \
-DCMAKE_CXX_COMPILER=/tmp/upstream-llvm-readonly/bin/clang++ \
-DLLVM_INCLUDE_TESTS=TRUE -DLLVM_ENABLE_ASSERTIONS=TRUE \
-DCOMPILER_RT_INCLUDE_TESTS=TRUE -DCOMPILER_RT_DEBUG=OFF \
-DLLVM_ENABLE_RUNTIMES=compiler-rt \
-DCMAKE_DISABLE_FIND_PACKAGE_LLVM=TRUE \
-DCMAKE_DISABLE_FIND_PACKAGE_Clang=TRUE \
-G Ninja -S ~/upstream-llvm-project/runtimes \
-B ~/upstream-llvm-project/runtimes/cmake-build-debug-llvm-git
```
Pull Request: https://github.com/llvm/llvm-project/pull/114307
I've run into an issue where TSan can't be used on some code without
turning off deadlock detection because a thread tries to hold too many
mutexes. It would be preferable to be able to use deadlock detection as
that is a major benefit of TSan.
Its mentioned in https://github.com/google/sanitizers/issues/950 that
the 64 mutex limit was an arbitrary number. I've increased it to 128 and
all the tests still pass. Considering the increasing number of cores on
CPUs and how programs can now use more threads to take advantage of it,
I think raising the limit to 128 would be some good future proofing
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
This function is always examining its own ELF headers in memory, but it
was trying to use conditions between examining files or memory, and it
wasn't accounting for LOAD offsets at runtime. This is especially bad if
a loaded segment has additional padding that's not in the file offsets.
Now we do a first scan of the program headers to figure out the runtime
base address based on `PT_PHDR` and/or `PT_DYNAMIC` (else assume zero),
similar to libc's `do_start`. Then each `PT_NOTE` pointer is simply the
base plus the segments's `pt_vaddr`, which includes LOAD offsets.
Fixes#114605
Following the example of tsan, where we took the name
This would allow users to determine if they want to see ALL output from
rtsan.
Additionally, remove the UNLIKELY hint, as it is now up to the flag whether or
not it is likely that we go through this conditional.
This calls the system calls switch_pri and sys_ulock_wait. It also is
one of the more straightforwardly rt-unsafe, in that it gives up this
thread's timeslice.
This tests that a simple C++ static initializer works as expected.
Compared to the architecture specific, assembly level regression tests for the
ORC runtime; this test is expected to catch cases where the compiler adopts
some new MachO feature that the ORC runtime does not yet support (e.g. a new
initializer section).
## Why we think this are unsafe
Again, these correspond directly to system calls on linux and OSX. They
are two ways to do interprocess communication so it would make sense
that they take some synchronization by the OS.
Certain tests (many are from lld/test) run `... '2>&1 | count 0` to
ensure that there is no stderr message.
GetRegistersAndSP may rarely fail, leading to
a spurious failure like (with a local hack to make `count` dump the
input):
```
+ /home/ray/llvm/out/asan/bin/ld.lld func1-gcs.o func2-gcs.o func3-gcs.o -o /dev/null -z gcs-report=warning -z gcs=never
+ /home/ray/llvm/out/asan/bin/count 0
Expected 0 lines, got 1.
==2403039==Unable to get registers from thread 2403018.
```
The failure can reliably be reproduced by running `ninja check-lld` a
few times under asan+lsan (see the bot
sanitizer-x86_64-linux-bootstrap-asan).
# Why we think these are real-time unsafe
They correspond directly to system calls in linux and OSX, they are
manipulating a shared resource, which likely takes some operating-system
synchronization.
Adding support for the extra SUMMARY line that is output by most
compilers. This also adds the ability for end-users to specify their own
handlers for reporting these errors (see the test).
Original commit 2ec5c69b68 only
intercepted timer_create.
Because of how versioned libc symbols work, this could cause problems
where a newer `timer_create`
was used, and the result would be used by an older version. This would
cause crashes. This is why we
need to intercept all of the related functions.
Addresses https://github.com/llvm/llvm-project/issues/111847
Intercepts in the family of `poll`, `select` and modern equivalents
`epoll` (linux only) and `kqueue` bsd family only.
These calls mirror the names of the system calls they call, which have
been verified on mac at least (e.g. kevent calls the system call
kevent).
