The existing ELF/COFF correlation code mostly "just works" on Mach-O
files, with one gotcha: on disk, the pointers in `__llvm_covdata` are
stored in an encoded format due to dyld fixup chains. (In memory, they
would normally be fixed up at load time in a running binary, but the
correlator only looks at the on-disk values.)
LLVM's Mach-O reader knows how to decode the format, so this patch walks
the fixup table to create a set of mappings that the correlator can use
to resolve the values.
rdar://168259786
On AIX, when both the `__VEC__` and `_ALL_SOURCE` macros are defined
(they are defined by default), the malloc and calloc system calls are
mapped to vec_malloc and vec_calloc respectively, so we need the
following vec_malloc and vec_calloc interceptors.
Issue: #138916
The `UBSan-Standalone-x86_64 :: TestCases/Misc/Posix/static-link.cpp`
test currently `FAIL`s on Solaris/x86_64 with
```
ld: fatal: option '-z record' is incompatible with building a static executable
```
One cannot create static executables on Solaris since no `libc.a` is
delivered, so this patch skips the test.
Tested on `x86_64-pc-solaris2.11`.
The `__cxa_atexit` interceptor is disabled for `SANITIZER_AIX` because
Clang on AIX neither uses `__cxa_atexit` nor links against a library
with such. This interceptor calls `StopInitOrderChecking()`, which is
needed to prevent false positives for the `initialization-order-fiasco`
error observed in the asan test `init-order-atexit.cpp` that uses the
`strict_init_order` flag. For now, we'll disable the `strict_init_order`
flag, but we'll look to support it in the future by implementing an
`exit` interceptor or some other alternative. With the flag disabled, we
won't update `init-order-atexit.cpp` to ensure it continues to pass and
the false positive doesn't show up.
Currently, the AIX linker and loader do not provide a mechanism to
implement ifuncs similar to GNU_ifunc on ELF Linux.
On AIX, we will lower `__attribute__((ifunc("resolver"))` to the llvm
`ifunc` as other platforms do. The llvm `ifunc` in turn will get lowered
at late stages of the optimization pipeline to an AIX-specific
implementation. No special linkage or relocations are needed when
generating assembly/object output.
On AIX, a function `foo` has two symbols associated with it: a function
descriptor (`foo`) residing in the `.data` section, and an entry point
(`.foo`) residing in the `.text` section. The first field of the
descriptor is the address of the entry point. Typically, the address
field in the descriptor is initialized once: statically, at load time
(?), or at runtime if runtime linking is enabled.
Here we would like to use the address field in the descriptor to
implement the `ifunc` semantics. Specifically, the ifunc function will
become a stub that jumps to the entry point in the address field. A
constructor function is linked into every linkage module. The
constructor walks an array of `{descriptor, resolver}` pairs, calling
the resolver and saving the result in the address field in the
descriptor (thus setting `foo`'s descriptor to point to the resolved
version early during program runtime).
Known limitations:
- Due to bug #161576, which affects object generation path, you will
need either `-ffunction-sections` or `-fno-integrated-as` to generate a
correct/linkable object file.
- aliases to ifuncs are not supported, a testcase has been added and
marked XFAIL. I'm planning to address in a follow-up PR because it's not
important enough, IMHO, for this PR
- dead ifuncs in a CU that contains at least one live ifunc, will result
in all ifuncs being kept by the linker. The fix for this is common with
a similar problem we have with PGO. PR #159435 is trying to provide a
mechanism that will allow the ifunc and PGO implementations to avoid the
dead code retention at the link step.
- the resolver must return a function that is in the same DSO as the
ifunc; the compiler will try to detect if this condition is violated and
report it, but it cannot detect it in general. To be safe, all candidate
functions (returned by a particular resolver) must either be static or
have hidden/protected visibility. This is so that the ifunc stub doesn't
have to save and restore the TOC register r2. In future work, this case
will be supported and the requirement will be lifted.
---------
Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
This patch adds implementations for the __aeabi_uread and __aeabi_uwrite
helper functions to compiler-rt.
Without these helpers, LLVM would need to inline byte wise sequences ,
which can increases code size, especially at -Os/-Oz. Using the helper
functions allows to retain correctness while avoiding the code-size
growth.
GCC-based toolchains already provide these AEABI helpers, so supporting
them in compiler-rt ensures parity and avoids accidental dependencies on
libgcc when LLVM begins emitting these calls.
This PR fixes
1. issue #175509 about missing support of deinitialize on ELF platform.
2. missing support of execution order by proirity at both initialize and
deinitialize stage.
cc: @tqchen @joker-eph
As `\+` is a GNU extension, it is not supported by the system grep on
AIX. This change replaces `%[0-9]\+` with `%[0-9][0-9]*`, which is
POSIX-compliant and therefore compatible with AIX.
There is an issue in certain versions of LD which causes the wrong
libLTO to be used if the DYLD_LIBRARY_PATH is not normalized.
Will fix these failures:
```
AddressSanitizer-x86_64-darwin.TestCases/Darwin.odr-lto.cpp
AddressSanitizer-x86_64h-darwin.TestCases/Darwin.odr-lto.cpp
```
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-cmake-RA-incremental/13428/
rdar://168024431
LSan, by design, can have false negatives, making it unreliable to check
that the leak was found in the stack-allocated case:
```
==123685==Scanning STACK range 0x7ffe6e554ca0-0x7ffe6e557000.
==123685==0x7ffe6e554de0: found 0x51e0000009f0 pointing into chunk 0x51e000000000-0x51e000000c00 of size 3072.
==123685==0x7ffe6e554e30: found 0x51e000000c00 pointing into chunk 0x51e000000c00-0x51e000001668 of size 2664. <- this prevented the leak from being found
```
This has led to flakiness on the buildbots e.g.,
https://lab.llvm.org/buildbot/#/builders/66/builds/24669
```
# | /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lsan/TestCases/swapcontext.cpp:44:11: error: CHECK: expected string not found in input
# | // CHECK: SUMMARY: {{.*}}Sanitizer: 2664 byte(s) leaked in 1 allocation(s)
...
Failed Tests (2):
LeakSanitizer-HWAddressSanitizer-x86_64 :: TestCases/swapcontext.cpp
LeakSanitizer-Standalone-x86_64 :: TestCases/swapcontext.cpp
```
This patch fixes the issue by clearing the buffer, as suggested by
Vitaly.
Some tests are already supported on "remote" devices and simulators.
However, there is currently no way to distinguish a remote macOS host
from a local one.
This adds the darwin-remote feature which is common to all test targets
which use a wrapper script (e.g. iossim_run.py).
rdar://167735355
---------
Co-authored-by: Dan Blackwell <danblackwell95@gmail.com>
The option added in #174522 breaks simulator tests, since `set_default`
overrides `False` values with the default.
Since these options are either string or boolean, this patches
set_default to override only un-set or empty string values (empty string
is not truth-y and therefore would be overwritten by defaults currently,
so this is NFCI)
Darwin supports running tests on targets other than the host machine
e.g. simulators. In such configurations, tests are run via a wrapper
script (e.g. iossim_run.py).
This refactors the lit test config to use a dedicated option to
distinguish test suites that run on the host from those that run in any
other configuration. This will allow the test suites to distinguish a
local osx configuration from a "remote" one.
rdar://167591463
After #171941, there are two issues:
First, some buildbots that use the old-style build are failing at:
```
Target ${BUILTIN_LIB_TARGET_NAME} does not exist"
```
Example failure:
https://lab.llvm.org/buildbot/#/builders/139/builds/25097
...during CMake configure. This appears to be caused by mismatch between
the builtin library's _target_ name and the output name from
set_output_name. This reverts the change to BUILTIN_LIB_TARGET_NAME made
by #171941, but still use the output name for naming the .sources.txt
file used for configuring builtins tests.
Second, this speculatively fixes an issue caused by two builtins
libraries that are produced with the same name in different directories
because of `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` (e.g.
`lib/clang/22/lib/i386-unknown-linux-gnu/libclang_rt.builtins.a` and
`lib/clang/22/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a`), and
thus the `.sources.txt` paths alias. This causes us to run the wrong
tests against one of the builtins libraries. The chosen fix is to store
the .sources.txt files in `get_compiler_rt_output_dir` (which takes
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` into account) rather than
`CMAKE_BINARY_DIR`.
As a side-effect, this allows for the replacement of
`COMPILER_RT_TEST_BUILTINS_DIR` with a simpler boolean option
`COMPILER_RT_TEST_EXTERNAL_BUILTINS`.
Example failure:
https://lab.llvm.org/buildbot/#/builders/66/builds/24433
This fixes cmake error from
https://github.com/llvm/llvm-project/pull/171941 in chrome's llvm build
where we have `COMPILER_RT_BUILD_BUILTINS=OFF` and have
`COMPILER_RT_TEST_BUILTINS_DIR` set. That change makes it to depend on
`crt` even if we don't have it in the prebuilt dir.
Log:
```
CMake Error at CMakeLists.txt:349 (add_dependencies):
The dependency target "crt" of target "runtimes-test-depends" does not
exist.
CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2104 (add_dependencies):
The dependency target "crt" of target "check-runtimes" does not exist.
Call Stack (most recent call first):
/b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2145 (add_lit_target)
CMakeLists.txt:353 (umbrella_lit_testsuite_end)
CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/test/CMakeLists.txt:127 (add_dependencies):
The dependency target "crt" of target "compiler-rt-test-depends" does not
exist.
CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2104 (add_dependencies):
The dependency target "crt" of target "check-compiler-rt" does not exist.
Call Stack (most recent call first):
/b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2145 (add_lit_target)
/b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/test/CMakeLists.txt:129 (umbrella_lit_testsuite_end)
CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2104 (add_dependencies):
The dependency target "crt" of target "check-builtins" does not exist.
Call Stack (most recent call first):
/b/s/w/ir/cache/builder/src/third_party/llvm/llvm/cmake/modules/AddLLVM.cmake:2171 (add_lit_target)
/b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/test/builtins/CMakeLists.txt:137 (add_lit_testsuite)
```
The shell feature only implies that we are not running on Windows now
that the internal shell is enabled by default everywhere. Remove where
we can and rewrite to the more intentional UNSUPPORTED: system-windows
when we still need to prevent tests from running on Windows.
When the `symbolize_inline_frames` option is set, we should use the `-i`
atos option and show inline frames.
The implementation is modeled after `ParseSymbolizePCOutput` and is now
quite close to that, but there are some subtle differences which I think
make it difficult to merge the implementations.
rdar://165894291
`COMPILER_RT_STANDALONE_BUILD` is set when doing a
`LLVM_ENABLE_RUNTIMES` build. This prevents the sanitizer runtimes from
being added as dependencies to `check-sanitizer`. Currently, if you make
runtime changes and then run `check-sanitizer` you won't actually be
testing a rebuilt runtime.
I don't follow why `COMPILER_RT_STANDALONE_BUILD` is even relevant here
(was it ever?), so the right thing to do may be to remove the check
entirely instead of adding `OR LLVM_RUNTIMES_BUILD` like I'm doing
here..
rdar://165894534
Commit c6f501d479e8 fixed an issue where some tests were incorrectly
marked as unsupported for a bootstrapping build. This exposed in our
'slow' full-bootstrap qemu-system CI that the fdr-mode.cpp fails on
RISC-V. We mark it as unsupported. I believe _xray_ArgLoggerEntry needs
to be implemented in xray_trampoline_risc*.S for this to work.
This test has begun failing on iossim with 'sh: sort: command not found'
in the stderr. I believe this may be due to the change to the lit
internal shell not having 'sort' in it's path.
This patch adds the full path /usr/bin/sort to work around this.
This commit addresses a longstanding TODO comment, by doing the
following:
* Modifies the CMakeLists to add the new test configs
* Modifies the relevant lit file to add the required envs
* Fixes the FileCheck match in
`Darwin/symbolizer-function-offset-atos.cpp`
* XFAILs any appropriate tests
rdar://107758331
Use mmap.PAGESIZE and fallback to os.sysconf if it is not available.
This allows to query the page size on Windows too, which has mmap but
not sysconf.
This is a pedantic change because Windows has a fixed page size of 4KiB.
I found this solution independently of #168857, and thought it might be
worth committing, since this is technically more correct.
[mmap.PAGESIZE implementation in
CPython](88cd5d9850/Modules/mmapmodule.c (L47))
When doing a LLVM_ENABLE_RUNTIMES-based build of clang+compiler_rt, the
`check-builtins` target is missing and builtins tests are not run
(#112105, #144090).
This provides one possible path forward for enabling these tests.
The approach taken here is to test the builtins with the `compiler-rt`
runtime build (i.e. only if you pass
`LLVM_ENABLE_RUNTIMES='compiler-rt'`). The builtins tests currently rely
on shared test infrastructure in `compiler-rt/`, so this is probably the
easiest solution without relocating the builtins and their tests outside
of `compiler-rt/`.
The main challenge is that the built-ins test configuration expects to
be able to inspect the builtin target and see the sources used to build
it:
```
get_target_property(BUILTIN_LIB_SOURCES "${BUILTIN_LIB_TARGET_NAME}" SOURCES)
```
Since the builtins build and runtimes build are separate under
LLVM_ENABLE_RUNTIMES, this target inspection is not possible. To get
around this, we write a temporary file alongside each builtins library
containing the list of sources (e.g.
`"${CMAKE_BINARY_DIR}/clang_rt.builtins-${arch}.sources.txt"`). Then, we
introduce an undocumented compiler-rt option
`COMPILER_RT_FORCE_TEST_BUILTINS_DIR` (which is only intended to be used
by the LLVM_ENABLE_RUNTIMES build, and could be removed after builtins
re relocated) that passes the path to the directory containing this
file, and configures builtins tests (even though the runtimes build has
`COMPILER_RT_BUILD_BUILTINS=OFF`)
rdar://163518748
This test is failing on some buildbots now that the internal shell has
been turned on and was failing previously on some ppc bots when turning
it on a while back (before it got reverted).
At least one X86 bot is barely hitting the limit
(https://lab.llvm.org/buildbot/#/builders/174/builds/28487 224MB-235MB).
This likely needs to be bumped due to changes in the process tree (now
that we invoke things through python rather than a bash shell) with the
enablement of the internal shell.
I have seen a failure whereby the fuzzer failed to reach the expected
input and thus failed the test.
This patch bumps the max executions to 10,000,000 in order to give the
fuzzer a better chance of reaching the expected input. Most runs
complete successfully, so I do not see this adding test time in the
general case; I believe it's a fair tradeoff for the unlucky seed to run
for longer if it reduces the noise from false positives. Note, this
updates a different `RUN:` to
https://github.com/llvm/llvm-project/pull/165402.
rdar://162122184
The recent relanding of the internal shell broke one of the debuginfod
tests as it is not tested by any upstream buildbot due to the use of
curl. Rewriting the test to not use subshells is pretty simple.
This reverts commit c90fb56b41cfaaee448700f6b068c830d8d0b5bd.
The failures identified in the revert commit have noe been fixed:
1. 4bc783be2dab2b0b2b3010158891e44a2b4ee991
2. 126462035a1eb7adeb97f6beac48b6bddac65d09
3. d7307f458cd3522470859ce0cee8d47d37a70670
Intended use-case is for threads that use (or switch to) stack with
special properties e.g. backed by MADV_DONTDUMP memory.
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
