This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these versions of clang, passing `-msse4.2` is insufficient
to enable the instructions and causes build failures when `-march` does
not enable CRC32 implicitly:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Use __builtin_ia32*() rather than _mm_crc32*() when using `-mcrc32`
to preserve compatibility with GCC. _mm_crc32*() are aliases
to __builtin_ia32*() in both compilers but GCC requires `-msse4.2`
for the former, while both use `-mcrc32` for the latter.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
This reverts commit 09b53121c3.
Breaks the build with GCC 11.2 on x86_64:
In file included from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.h:27,
from /home/npopov/repos/llvm-project/compiler-rt/lib/scudo/scudo_crc32.cpp:14:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h: In function ‘__sanitizer::u32 __scudo::computeHardwareCRC32(__sanitizer::u32, __sanitizer::uptr)’:
/usr/lib/gcc/x86_64-redhat-linux/11/include/smmintrin.h:846:1: error: inlining failed in call to ‘always_inline’ ‘long long unsigned int _mm_crc32_u64(long long unsigned int, long long unsigned int)’: target specific option mismatch
846 | _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`. The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608af4.
With these compilers, passing `-msse4.2` is insufficient to enable
the instructions and causes build failures when `-march` does not enable
CRC32:
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
return CRC32_INTRINSIC(Crc, Data);
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
# define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
^
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
# define FIRST_32_SECOND_64(a, b) (a)
^
1 error generated.
For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`. The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.
Originally reported in https://bugs.gentoo.org/835870.
Differential Revision: https://reviews.llvm.org/D122789
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This is a restricted alternative to D91605
<https://reviews.llvm.org/D91605> which only works on Solaris 11.4 SRU 10+,
but would break the build on Solaris 11.3 and Illumos which lack
`dlpi_tls_modid`.
Apart from that, the patch is trivial. One caveat is that the
`sanitizer_common` and `asan` tests need to be linked explicitly with `ld
-z relax=transtls` on Solaris/amd64 since the archives with calls to
`__tls_get_addr` are linked in directly.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D120048
This reverts commit 910a642c0a.
There are serious correctness issues with the current approach: __sync_*
routines which are not actually atomic should not be enabled by default.
I'll continue discussion on the review.
ARMv5 and older architectures don’t support SMP and do not have atomic instructions. Still they’re in use in IoT world, where one has to stick to libgcc.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D116088
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
Petr Hosek