We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.
This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
indirect branch tracking(IBT) feature aiming to ensure the target address
of an indirect jump/call is not tampered.
When IBT is enabled, each function or target of any indirect jump/call will start
with an 'endbr32/64' instruction otherwise the program will crash during execution.
To build an application with CET enabled. we need to ensure:
1. build the source code with "-fcf-protection=full"
2. all the libraries linked with .o files must be CET enabled too
This patch aims to enable CET for compiler-rt builtins library, we add an option
"COMPILER_RT_ENABLE_CET" whose default value is OFF to enable CET for compiler-rt
in building time and when this option is "ON", "-fcf-protection=full" is added to
BUILTINS_CFLAG and the "endbr32/64" will be placed in the beginning of each assembly
function. We also enabled CET for crtbegin, crtend object files in this patch.
Reviewed by: MaskRay, compnerd, manojgupta, efriedma
Differential Revision: https://reviews.llvm.org/D109811
Signed-off-by: jinge90 <ge.jin@intel.com>
Currently, SANITIZER_COMMON_SUPPORTED_OS is being used to enable many libraries.
Unfortunately this makes it impossible to selectively disable a library based on the OS.
This patch removes this limitation by adding a separate list of supported OSs for the lsan, ubsan, ubsan_minimal, and stats libraries.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D113444
Applying the same rules as for LLVM_BUILD_INSTRUMENTED build in the cmake files.
By having this patch, we are able to disable/enable instrument+coverage build
of the compiler-rt project when building instrumented LLVM.
Differential Revision: https://reviews.llvm.org/D108127
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
Reapply 5692ed0cce, but with the ORC runtime disabled explicitly on
CrossWinToARMLinux to match the other compiler-rt runtime libraries.
Differential Revision: https://reviews.llvm.org/D112229
---
Enable building the ORC runtime for 64-bit and 32-bit ARM architectures,
and for all Darwin embedded platforms (iOS, tvOS, and watchOS). This
covers building the cross-platform code, but does not add TLV runtime
support for the new architectures, which can be added independently.
Incidentally, stop building the Mach-O TLS support file unnecessarily on
other platforms.
Differential Revision: https://reviews.llvm.org/D112111
Enable building the ORC runtime for 64-bit and 32-bit ARM architectures,
and for all Darwin embedded platforms (iOS, tvOS, and watchOS). This
covers building the cross-platform code, but does not add TLV runtime
support for the new architectures, which can be added independently.
Incidentally, stop building the Mach-O TLS support file unnecessarily on
other platforms.
Differential Revision: https://reviews.llvm.org/D112111
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
Previously we used the minimum deployment target used for the platform
(e.g. iOS is 9.0). Unfortunately this leads to ABI incompatibilities with
arm64e devices running newer OSs. In particular the following TSan test
cases that used libcxx would fail due to the ABI mismatch.
* Darwin/libcxx-shared-ptr-recursive.mm
* Darwin/libcxx-shared-ptr-stress.mm
* Darwin/libcxx-shared-ptr.mm
* libcxx/std_shared_ptr.cpp
Given that arm64e is not ABI stable we should ideally match the
deployment target for sanitizer runtimes and their tests cases to the
device when building for arm64e. Unfortunately having a mixed deployment
target (based on architecture) isn't currently supported by the build system
and is non-trivial to implement.
As a stop-gap measure this patch changes the sanitizer test suites (but not the
sanitizer runtimes themselves) to use a newer deployment target when
targetting arm64e.
The deployment target used for arm64e is the SDK version because this
"should" match the OS version running on the target device (it is a
configuration error to not match them).
rdar://83080611
9ee64c3746 has started using
COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG inside scudo. However,
the relevant CMake check was performed in builtin-config-ix.cmake,
so the definition was missing when builtins were not built. Move
the check to config-ix.cmake, so that it runs unconditionally of
the components being built.
Fixes PR#51847
Differential Revision: https://reviews.llvm.org/D109812
This updates llvm/utils/sysroot.py to include the "DIA SDK" folder in the
sysroot.
It also updates the build to look for the DIA SDK there if a sysroot is set.
This requires moving LLVM_WINSYSROOT to config-ix.cmake.
For the GN build, I chose to pass a qualified path to diaguids in libs instead
of pushing a config with a `/libpath:` flag. The former requires a GN with
https://gn-review.googlesource.com/c/gn/+/12200, the latter requires D109624.
The former is more like the cmake build, arguably a bit simpler, and it's
easier to check for the wrong GN revision and easier to update GN.
Differential Revision: https://reviews.llvm.org/D109708
The __attribute__((format)) was added somewhere in 2012,
the lost during refactoring, then re-added in 2014 but
to te source files, which is a no-op.
Move it back to header files so that it actually takes effect.
But over the past 7 years we've accumulated whole lot of
format string bugs of different types, so disable the warning
with -Wno-format for now for incremental clean up.
Among the bugs that it warns about are all kinds of bad things:
- wrong sizes of arguments
- missing/excessive arguments
- printing wrong things (e.g. *ptr instead of ptr)
- completely messed up format strings
- security issues where external string is used as format
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107977
When the builtins library isn't found, find_compiler_rt_library
returns NOTFOUND so we'll end up linking against -lNOTFOUND. We need
to check the return value before adding it to the list.
Differential Revision: https://reviews.llvm.org/D107627
This change adds tests to make sure that SCUDO is being properly
included with llvm libc. This change also adds the toggles to properly
use SCUDO, as GWP-ASan is enabled by default and must be included for
SCUDO to function.
Reviewed By: sivachandra, hctim
Differential Revision: https://reviews.llvm.org/D106919
Adds extra supported architectures that were available for vanilla
scudo, in preparation for D102543. Hopefully the dust has settled and
7d0a81ca38 is no longer an issue.
Reviewed By: cryptoad, vitalybuka
Differential Revision: https://reviews.llvm.org/D102648
Add unit test infrastructure for the ORC runtime, plus a cut-down
extensible_rtti system and extensible_rtti unit test.
Removes the placeholder.cpp source file.
Differential Revision: https://reviews.llvm.org/D102080
Rename `check_linker_flag` in compiler_rt to avoid conflict. Follow up
as the fix in D100901.
Patched by radford.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101581
This reapplies 1e1d75b190, which was reverted in ce1a4d5323 due to build
failures.
The unconditional dependencies on clang and llvm-jitlink in
compiler-rt/test/orc/CMakeLists.txt have been removed -- they don't appear to
be necessary, and I suspect they're the cause of the build failures seen
earlier.
Some builders failed with a missing clang dependency. E.g.
CMake Error at /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build \
/lib/cmake/llvm/AddLLVM.cmake:1786 (add_dependencies):
The dependency target "clang" of target "check-compiler-rt" does not exist.
Reverting while I investigate.
This reverts commit 1e1d75b190.
This seems to be a safe way to ensure that the Compiler-RT test compiler
flags are properly set in all cross-compilation scenarios. Without this
when `BUILTINS_TEST_TARGET_CFLAGS` is set in
`compiler-rt/test/builtins/CMakeLists.txt` the other flags are cleared.
Differential Revision: https://reviews.llvm.org/D92124
SX Aurora VE is an experimental target. We upstreamed many part of
ported llvm and clang. In order to continue this move, we need to
support libraries next, then we need to show the ability of llvm for
VE through test cases. As a first step for that, we need to use
crt in compiler-rt. VE has it's own crt but they are a part of
proprietary compiler. So, we want to use crt in compiler-rt as an
alternative.
This patch enables VE as a candidate of crt in compiler-rt.
Reviewed By: phosek, compnerd
Differential Revision: https://reviews.llvm.org/D92748
Reland: a2291a58bf.
New fixes for the breakages reported in D85927 include:
- declare a weak decl for `dl_iterate_phdr`, because it does not exist on older APIs
- Do not enable leak-sanitizer if api_level is less than 29, because of `ld.lld: error: undefined symbol: __aeabi_read_tp` for armv7, API level 16.
- Put back the interceptor for `memalign` but still opt out intercepting `__libc_memalign` and `cfree` because both of these don't exist in Bionic.
Reviewed By: srhines, vitalybuka
Differential Revision: https://reviews.llvm.org/D89251
This patch adds support for building the compiler-rt profile library on AIX.
Reviewed by: phosek
Differential Revision: https://reviews.llvm.org/D90619
John Ericson