These UBSan tests assert the absence of runtime errors via `count 0`,
which means "expect no output". This fails the test unnecessarily in
some environments (e.g., iOS simulator in our case). Alter the test to
be a bit more specific and "expect no error" instead of "expect no
output".
rdar://65503408
Differential Revision: https://reviews.llvm.org/D85155
GlobalISel is the default ISel for aarch64 at -O0. Prior to D78465, GlobalISel
didn't have support for dealing with address-of-global lowerings, so it fell
back to SelectionDAGISel.
HWASan Globals require special handling, as they contain the pointer tag in the
top 16-bits, and are thus outside the code model. We need to generate a `movk`
in the instruction sequence with a G3 relocation to ensure the bits are
relocated properly. This is implemented in SelectionDAGISel, this patch does
the same for GlobalISel.
GlobalISel and SelectionDAGISel differ in their lowering sequence, so there are
differences in the final instruction sequence, explained in
`tagged-globals.ll`. Both of these implementations are correct, but GlobalISel
is slightly larger code size / slightly slower (by a couple of arithmetic
instructions). I don't see this as a problem for now as GlobalISel is only on
by default at `-O0`.
Reviewed By: aemerson, arsenm
Differential Revision: https://reviews.llvm.org/D82615
Extend the memop value profile buckets to be more flexible (could accommodate a
mix of individual values and ranges) and to cover more value ranges (from 11 to
22 buckets).
Disabled behind a flag (to be enabled separately) and the existing code to be
removed later.
Differential Revision: https://reviews.llvm.org/D81682
Currently, several InstrProf tests `FAIL` on Solaris (both sparc and x86):
Profile-i386 :: Posix/instrprof-visibility.cpp
Profile-i386 :: instrprof-merging.cpp
Profile-i386 :: instrprof-set-file-object-merging.c
Profile-i386 :: instrprof-set-file-object.c
On sparc there's also
Profile-sparc :: coverage_comments.cpp
The failure mode is always the same:
error: /var/llvm/local-amd64/projects/compiler-rt/test/profile/Profile-i386/Posix/Output/instrprof-visibility.cpp.tmp: Failed to load coverage: Malformed coverage data
The error is from `llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp`
(`loadBinaryFormat`), l.926:
InstrProfSymtab ProfileNames;
std::vector<SectionRef> NamesSectionRefs = *NamesSection;
if (NamesSectionRefs.size() != 1)
return make_error<CoverageMapError>(coveragemap_error::malformed);
where .size() is 2 instead.
Looking at the executable, I find (with `elfdump -c -N __llvm_prf_names`):
Section Header[15]: sh_name: __llvm_prf_names
sh_addr: 0x8053ca5 sh_flags: [ SHF_ALLOC ]
sh_size: 0x86 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x3ca5 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1
Section Header[31]: sh_name: __llvm_prf_names
sh_addr: 0x8069998 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x9998 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1
Unlike GNU `ld` (which primarily operates on section names) the Solaris
linker, following the ELF spirit, only merges input sections into an output
section if both section name and section flags match, so two separate
sections are maintained.
The read-write one comes from `lib/clang/12.0.0/lib/sunos/libclang_rt.profile-i386.a(InstrProfilingPlatformLinux.c.o)`
while the read-only one is generated by
`llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp` (`InstrProfiling::emitNameData`)
at l.1004 where `isConstant = true`.
The easiest way to avoid the mismatch is to change the definition in
`compiler-rt/lib/profile/InstrProfilingPlatformLinux.c` to `const`.
This fixes all failures observed.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D85116
The root cause was fixed by 3d6f53018f.
The workaround added in 99ad956fda can be changed
to an assert now. (In case the fix regresses, there will be a heap-use-after-free.)
Otherwise we end up compiling in C++ mode and on FreeBSD
/usr/include/stdatomic.h is not compatible with C++ since it uses _Bool.
Reviewed By: guiand, eugenis, vitalybuka, emaste
Differential Revision: https://reviews.llvm.org/D84510
See https://llvm.org/PR46862. This does not fix the underlying issue but at
least it allows me to run check-all again without having to disable
building compiler-rt.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D84650
A recent change broke `ninja check-asan` on Darwin by causing an error
during linking of ASan unit tests [1].
Move the addition of `-ObjC` compiler flag outside of the new
`if(COMPILER_RT_STANDALONE_BUILD)` block. It doesn't add any global
flags (e.g, `${CMAKE_CXX_FLAGS}`) and the decision to add is based
solely on source paths (`${source_rpath}`).
[1] 8b2fcc42b8, https://reviews.llvm.org/D84466
Differential Revision: https://reviews.llvm.org/D85057
`TARGET_OS_IOS` and `TARGET_OS_WATCH` are not mutually exclusive.
`SANITIZER_IOS` is defined for all embedded platforms. So the branch
for watchOS is never taken. We could fix this by switching the order
of the branches (but the reason for doing so is non-obvious). Instead,
lets use the Darwin-specific `TARGET_OS_*` macros which are mutually
exclusive.
We want the Go build to not use getauxval, as we must support glibc < 2.16 platforms.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D84859
There are some files in compiler-rt that use UTF-8 characters in some of the
comments. This causes lint failures with some versions of Python. This patch
just makes the encoding explicit in the call to open.
InstrProfilingBuffer.c.o is generic code that must support compilation
into freestanding projects. This gets rid of its dependence on the
_getpagesize symbol from libc, shifting it to InstrProfilingFile.c.o.
This fixes a build failure seen in a firmware project.
rdar://66249701
Not matching the (real) variadic declaration makes the interceptor take garbage inputs on Darwin/AArch64.
Differential Revision: https://reviews.llvm.org/D84570
As requested in the review, this patch removes the additional conditions in
the `COMPILER_RT_HAS_VERSION_SCRIPT` tests.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D84559
Add a fallback for `sysctl kern.osproductversion` for XNU 17 (macOS
10.13) and below, which do not provide this property.
Unfortunately, this means we have to take the detour via Darwin kernel
version again (at least for the fallback).
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D84892
for device simulators
This change separates out the iOS/tvOS/watchOS simulator slices from the "libclang_rt.<os>.a"
fat archive, by moving them out to their own "libclang_rt.<os>sim.a" static archive.
This allows us to build and to link with an arm64 device simulator slice for the simulators running
on Apple Silicons, and to distribute it in one archive alongside the Intel simulator slices.
Differential Revision: https://reviews.llvm.org/D84564
When attempting to build compiler-rt on a developer transition kit, the
build would fail due to `.S` files not being handled properly by the
Ninja generator. Rather than conditionalising on Xcode, conditionalise
to Darwin. Because we know that the system compiler is clang based, it
will always properly handle the pre-processing based on the extension.
Differential Revision: https://reviews.llvm.org/D84333
Adds the -fast-16-labels flag, which enables efficient instrumentation
for DFSan when the user needs <=16 labels. The instrumentation
eliminates most branches and most calls to __dfsan_union or
__dfsan_union_load.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D84371
-fno-lto is in SANITIZER_COMMON_CFLAGS but not here.
Don't use SANITIZER_COMMON_CFLAGS because of performance issues.
See https://bugs.llvm.org/show_bug.cgi?id=46838.
Fixes
$ ninja TScudoCUnitTest-i386-Test
on an LLVM build with -DLLVM_ENABLE_LTO=Thin.
check-scudo now passes.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D84805
...which is set based on HAVE_RPC_XDR_H. At least Fedora 32 does not have a
/usr/include/rpc/xdr.h, so failed this test introduced with
<https://reviews.llvm.org/D83358> "[Sanitizers] Add interceptor for
xdrrec_create".
Differential Revision: https://reviews.llvm.org/D84740
This adds the code to support calling mallopt and converting the
options to the internal Option enum.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D84806
This patch marks compiler-rt/test/asan/TestCases/Linux/allocator_oom_test.cpp
unsupported on PowerPC 64bit-LE architecture since this test fails when run
on a machine with larger system memory.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D84786
Summary:
Partners have requested the ability to configure more parts of Scudo
at runtime, notably the Secondary cache options (maximum number of
blocks cached, maximum size) as well as the TSD registry options
(the maximum number of TSDs in use).
This CL adds a few more Scudo specific `mallopt` parameters that are
passed down to the various subcomponents of the Combined allocator.
- `M_CACHE_COUNT_MAX`: sets the maximum number of Secondary cached items
- `M_CACHE_SIZE_MAX`: sets the maximum size of a cacheable item in the Secondary
- `M_TSDS_COUNT_MAX`: sets the maximum number of TSDs that can be used (Shared Registry only)
Regarding the TSDs maximum count, this is a one way option, only
allowing to increase the count.
In order to allow for this, I rearranged the code to have some `setOption`
member function to the relevant classes, using the `scudo::Option` class
enum to determine what is to be set.
This also fixes an issue where a static variable (`Ready`) was used in
templated functions without being set back to `false` every time.
Reviewers: pcc, eugenis, hctim, cferris
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D84667
Checking the OS version via `GetMacosAlignedVersion()` now works in
simulators [1]. Let's use it to simplify `DyldNeedsEnvVariable()`.
[1] 3fb0de8207
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D81197
compiler-rt checks OS versions by querying the Darwin kernel version.
This is not necessarily correct inside the simulators if the simulator
runtime is not aligned with the host macOS. Let's instead check the
`SIMULATOR_RUNTIME_VERSION` env var.
rdar://63031937
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D83977
In a build with -DLLVM_ENABLE_LTO=Thin:
$ ninja TSanitizer-x86_64-Test-Nolibc
[1/1] Generating Sanitizer-x86_64-Test-Nolibc
FAILED: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-x86_64-Test-Nolibc
sanitizer_nolibc_test_main.x86_64.o: file not recognized: file format not recognized
because -flto=thin is getting passed to the clang_compile step.
For non-standalone builds, global compilation flags shouldn't be passed to compiler-rt tests, only the flags the test specifies.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D84466
Neither the Illumos `ld` nor the Solaris 11.3 one support the `--version-script` and
`z gnu-linker-script-compat` options, which breaks the `compiler-rt` build.
This patch checks for both options instead of hardcoding their use.
Tested on `amd-pc-solaris2.11` (all of Solaris 11.4, 11.3, and Illumos).
Differential Revision: https://reviews.llvm.org/D84559
make_unique is a C++14 feature, and this prevents us from building on
Ubuntu Trusty. While we do use a C++14 compatible toolchain for building
in general, we fall back to the system toolchain for building the
compiler-rt tests.
The reason is that those tests get cross-compiled for e.g. 32-bit and
64-bit x86, and while the toolchain provides libstdc++ in those
flavours, the resulting compiler-rt test binaries don't get RPATH set
and so won't start if they're linked with that toolchain.
We've tried linking the test binaries against libstdc++ statically, by
passing COMPILER_RT_TEST_COMPILER_CFLAGS=-static-libstdc++. That mostly
works, but some test targets append -lstdc++ to the compiler invocation.
So, after spending way too much time on this, let's just avoid C++14
here for now.
The commit 8372d50508 has been reverted
(eafeb8af34) because it broke asan
tests on green dragon buildbots.
The underlying issue has been fixed in 4dd5c2bee3.
This adds a new extern "C" function that serves the same purpose. This removes the need for external users to depend on internal headers in order to use this feature. It also standardizes the interface in a way that other fuzzing engines will be able to match.
Patch By: IanPudney
Reviewed By: kcc
Differential Revision: https://reviews.llvm.org/D84561
Summary: This patch disables implicit builtin knowledge about memcmp-like functions when compiling the program for fuzzing, i.e., when -fsanitize=fuzzer(-no-link) is given. This allows libFuzzer to always intercept memcmp-like functions as it effectively disables optimizing calls to such functions into different forms. This is done by adding a set of flags (-fno-builtin-memcmp and others) in the clang driver. Individual -fno-builtin-* flags previously used in several libFuzzer tests are now removed, as it is now done automatically in the clang driver.
The patch was once reverted in 8ef9e2bf35, as this patch was dependent on a reverted commit f78d9fceea. This reverted commit was recommitted in 831ae45e3d, so relanding this dependent patch too.
Reviewers: morehouse, hctim
Subscribers: cfe-commits, #sanitizers
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D83987
Summary:
Fix up a slight bug with the crash handler API, where we say that we
return the size of the collected trace (instead of the size of the trace
that's returned) when the return buffer is too small, and the result is
truncated.
Also, as a result, patch up a small uninitialized memory bug.
Reviewers: morehouse, eugenis
Reviewed By: eugenis
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D84652
Fangrui Song