As discussed here:
https://github.com/llvm/llvm-project/pull/74394#issuecomment-2035264683
An unintentional change of behavior was introduced in #74394
This code introduced in #74394 :
The first time through
* SANITIZER_MIN_OSX_VERSION is not set
* parse -mmacosx-version-min and set MACOSX_VERSION_MIN_FLAG
* Set and cache SANITIZER_MIN_OSX_VERSION
Subsequent times through:
* SANITIZER_MIN_OSX_VERSION is cached
* (BUG!!) you don't parse -mmacosx-version-min, and don't set
MACOSX_VERSION_MIN_FLAG
MACOSX_VERSION_MIN_FLAG is used later in the file on this line:
63c925ca80/compiler-rt/cmake/config-ix.cmake (L517)
Hoisting this assignment outside the if block returns us to the previous
behavior before this commit, while maintaining the flexibility
introduced with the cache variable
Currently, the testsuite uses the default runtimes path to find the
runtimes libraries which may or may not match the just-built runtimes.
This change uses the `-resource-dir` flag for clang whenever
`COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` is set to ensure that we are
actually testing the currently built libraries rather than the ones
bundled with `${COMPILER_RT_TEST_COMPILER}`.
The existing logic works fine when clang and compiler-rt share the same
build directory ``-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`, but when
building compiler-rt separately we need to tell the compiler used for
the tests where it can find the just-built libraries.
This reduces the fixes check-all failures to one in my configuration:
```
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G Ninja
-DCMAKE_C_COMPILER=$HOME/output/upstream-llvm/bin/clang
-DCMAKE_CXX_COMPILER=$HOME/output/upstream-llvm/bin/clang++
-DCOMPILER_RT_INCLUDE_TESTS=ON
-DLLVM_EXTERNAL_LIT=$HOME/build/upstream-llvm-project-build/bin/llvm-lit
-DLLVM_CMAKE_DIR=$HOME/output/upstream-llvm
-DCOMPILER_RT_DEBUG=OFF
-S $HOME/src/upstream-llvm-project/compiler-rt
-B $HOME/src/upstream-llvm-project/compiler-rt/cmake-build-all-sanitizers
```
Reviewed By: vitalybuka, delcypher, MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/83088
compiler-rt may depend on libc (memset etc). Likewise a libc built by
clang may depend on compiler-rt builtins.
This circular dependency doesn't matter much once they're both compiled.
The easy compilation order to build both from source is:
1. install libc headers somewhere
2. build compiler-rt builtins against those headers
3. build libc against compiler-rt builtins
This patch relaxes the cmake sanity check to pass without requiring a
libc library. That allows the above sequence to work. Otherwise one
needs to build a static libc, then use that to pass the compiler-rt
cmake check, then build a normal libc.
The greendragon was recently moved and now it runs on somewhat newer
macOS
version - which breaks some sanitizers tests
rdar://125052915
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
Since this standalone build configuration uses the runtime libraries that
are being built just now, we need to ensure that e.g. the TSan unit tests
depend on the tsan runtime library. Also fix TSAN_DEPS being overridden
to not include the tsan runtime (commit .....).
This change fixes a build race seen in the CI checks for
TsanRtlTest-x86_64-Test in https://github.com/llvm/llvm-project/pull/83088.
Reviewed By: vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/83650
With https://github.com/llvm/llvm-project/pull/83088, we now need the
runtimes to be built before running test if
COMPILER_RT_TEST_STANDALONE_BUILD_LIBS is true, since otherwise we
get failures running `ninja check-all` such as the following:
```
/usr/bin/ld: cannot find .../compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.fuzzer-x86_64.a: No such file or directory
/usr/bin/ld: cannot find .../compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.xray-x86_64.a: No such file or directory
/usr/bin/ld: cannot find .../compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.xray-basic-x86_64.a: No such file or directory
/usr/bin/ld: cannot find .../compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.xray-fdr-x86_64.a: No such file or directory
```
This is a follow-up to 058e9b03 which started removing these checks
and it should make it easier to stop forcing COMPILER_RT_STANDALONE_BUILD
for runtimes builds in the future.
Reviewed By: vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/83651
These checks have been broken since 6afe972195.
The check_cxx_compiler_flag macro only takes two arguments and passing
three to it ends up calling
`cmake_check_compiler_flag(CXX "${_FLAG}" ${_RESULT})` with ${_FLAG}
equal to `-Werror` and the result variable being the actually tested
compiler flag.
I noticed this because some of the flags that I know should be supported
were being flagged as not supported. `--debug-trycompile` shows the
following surprising line in the generated CMakeLists.txt:
`add_definitions([==[-D-Wempty-body]==] [==[-Werror]==])` which then
results in the following error while running the check:
```
FAILED: CMakeFiles/cmTC_72736.dir/src.cxx.o
tmp/upstream-llvm-readonly/bin/clang++ -nodefaultlibs -std=c++17 -fcolor-diagnostics -D-Wempty-body -Werror -MD -MT CMakeFiles/cmTC_72736.dir/src.cxx.o -MF CMakeFiles/cmTC_72736.dir/src.cxx.o.d -o CMakeFiles/cmTC_72736.dir/src.cxx.o -c .../cmake-build-all-sanitizers/CMakeFiles/CMakeScratch/TryCompile-nyh3QR/src.cxx
In file included from <built-in>:450:
<command line>:1:9: error: macro name must be an identifier
1 | #define -Wempty-body 1
| ^
1 error generated.
```
It would be great if CMake could be a bit more helpful here so I've
filed https://gitlab.kitware.com/cmake/cmake/-/issues/25735.
See also https://reviews.llvm.org/D146920.
Reviewed By: nikic
Pull Request: https://github.com/llvm/llvm-project/pull/83779
The watchOS and tvOS sanitizers do not compile with publicly-available
SDKs, failing on calls such as fork() and posix_spawn(). Updating the
darwin_test_archs test program to include a call to fork() allows cmake
to exclude those platforms when compiling runtimes. This allows public
builds to enable watchOS/tvOS and compile builtins but not sanitizers.
I was getting build failures due to missing <cstddef> when building the
libfuzzer tests. It turns out that the custom command was using
COMPILER_RT_TEST_COMPILER when building the source file rather than
the COMPILER_RT_TEST_CXX_COMPILER.
Pull Request: https://github.com/llvm/llvm-project/pull/83090
It is desirable to be able to configure the `-mmacosx-version-min` flag
for the sanitizers, but this flag was never made a CACHE variable in
cmake.
By doing this, it will allow developers to select different minimum
versions, which results in different interceptors being enabled or
disabled on their platforms. This version can now persist between cmake
runs, so it can be remembered by cmake, and edited in the cache file.
When the top-level CMake invocation has `CMAKE_VERBOSE_MAKEFILE=ON`,
indicating the user wants to have verbose builds (i.e. all executed
commands explicitly echoed), some of the subprojects and runtimes (such
as compiler-rt, libcxx, etc) do not build in verbose mode. For example,
with Ninja:
```
[ 99% 6252/6308] cd /build/runtimes/builtins-bins && /usr/local/bin/cmake --build .
[ 0% 6/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvti2.c.o
[ 0% 7/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o
[ 0% 8/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvsi2.c.o
...
```
This is because `llvm_ExternalProject_Add()` and `add_custom_libcxx()`
use CMake's `ExternalProject_Add()` function to configure such
subproject builds, and do not pass through the `CMAKE_VERBOSE_MAKEFILE`
setting.
Similar to what is done in `clang/CMakeLists.txt`, add
`-DCMAKE_VERBOSE_MAKEFILE=ON` to the `ExternalProject_Add()` invocations
in `llvm_ExternalProject_Add()` and `add_custom_libcxx()`, whenever the
top-level CMake invocation had `CMAKE_VERBOSE_MAKEFILE` turned on.
Embedded Darwin platforms have generalized COMPILER_RT_ENABLE_<PLATFORM>
configuration settings, but currently 'osx' is always eabled on Darwin.
Add ORC_ENABLE_OSX to allow explicitly *disabling* the orc runtime for
macOS platform. This can be useful if you only want to build a specific
embedded platform. It would be nice to generalize this to handle other
compiler-rt projects (i.e. add COMPILER_RT_ENABLE_OSX), but would
require additional attention from each compiler-rt project.
Note: some tests currently only are configured for osx, so these are
disabled when osx is disabled.
GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.
Differential Revision: https://reviews.llvm.org/D153814
This can be used to configure runtimes builds (instead of setting flags
individually), and we need to pass it down to the custom libc++ build
for it to work correctly.
The Android LLVM build system builds the arm64 fuzzer lib without
HWASan, but then applications that enable HWASan can generated an object
file with a HWASan-ified version of some libc++ symbols (e.g.
`std::__1::piecewise_construct`). The linker can choose the HWASan-ified
definition, but then it cannot resolve the relocation from
libclang_rt.fuzzer-aarch64-android.a to this symbol because the high
bits of the address are unexpectedly set. This produces an error:
```
relocation R_AARCH64_ADR_PREL_PG_HI21 out of range
```
Fix this problem by linking a custom isolated libc++ into Android's
fuzzer library.
We need to pass through ANDROID_NATIVE_API_LEVEL so that the libc++ for
32-bit Android (API < 24) uses LLVM_FORCE_SMALLFILE_FOR_ANDROID.
compiler-rt/builtins doesn't depend on anything from the CRT but
currently links against it and embeds a `/defaultlib:msvcrt` in the
`.lib` file, forcing anyone linking against it to also link against that
specific CRT. This isn't necessary as the end user can just choose which
CRT they want to use independently.
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half
is used by kernel. There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is
ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36 Loader, vdso and other
libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27,
hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
D145214 was reverted because one file was missing in the latest commit.
Luckily the file was there in the previous commit, probably the author
missed uploading that file with latest commit.
Co-authored-by: Alex Fan <alex.fan.q@gmail.com>
Resolved issue with green dragon build by fixing relocations for
MachO/Darwin which doesn't compile without @page/@pageoff directives.
Also silenced a warning about constructor(90) priority being < 101,
which is reserved for the implementation. In this case, we're compiling
the implementation so we should be able to use 90.
This reverts commit 072713add4.
When compiling for SME and using the attributes to use PSTATE.ZA,
Clang will emit calls to SME ABI support routines to save and
restore ZA state.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D154045
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands a633a3761f with fixes.
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands b4435104ca with fixes.
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half is used by kernel.
There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36
Loader, vdso and other libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27, hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
If libc++ is available and should be used as the ubsan C++ ABI library,
the check for libc++ might fail if libc++ is a static library, as the
-nodefaultlibs flag inhibits a potential compiler default -lunwind.
Just like the -nodefaultlibs configuration tests for and manually adds a
bunch of compiler default libraries, look for -lunwind too.
This is a reland of #65912.
This reverts commit 64c0bddb76.
This seems to run into errors on some buildbots; configure errors
out like this:
-- Looking for _Unwind_RaiseException in unwind
-- Looking for _Unwind_RaiseException in unwind - not found
CMake Error at /usr/share/cmake-3.25/Modules/CheckLibraryExists.cmake:71 (try_compile):
Only libraries may be used as try_compile or try_run IMPORTED
LINK_LIBRARIES. Got unwind of type UTILITY.
Call Stack (most recent call first):
/b/sanitizer-aarch64-linux-fuzzer/build/llvm-project/compiler-rt/cmake/config-ix.cmake:66 (check_library_exists)
/b/sanitizer-aarch64-linux-fuzzer/build/llvm-project/compiler-rt/CMakeLists.txt:281 (include)
If libc++ is available and should be used as the ubsan C++ ABI library,
the check for libc++ might fail if libc++ is a static library, as the
-nodefaultlibs flag inhibits a potential compiler default -lunwind.
Just like the -nodefaultlibs configuration tests for and manually adds a
bunch of compiler default libraries, look for -lunwind too.
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
Move the code which sets CMake variables for MIPS to
compiler-rt/cmake/base-config-ix.cmake from compiler-rt/CMakeLists.txt.
compiler-rt/CMakeLists.txt includes compiler-rt/cmake/base-config-ix.cmake
very early. If the variables are set in compiler/CMakeLists.txt,
compiler-rt/cmake/base-config-ix.cmake cannot use them.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157900
Since jitlink for ppc64le is ready for general use, test cases in compiler-rt for ELFNixPlatform support can be enabled.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D156399
