This reverts commit 985486dca48bffd9e991d9f5ac32e1d109ae000f.
This seems to cause malformed profdata: crbug.com/1469456
(cherry picked from commit 4b08be77c98a4c15b8b3d634fab4ffc24bf4ef38)
The cacheflush is only defined with __USE_MISC, which depends on _DEFAULT_SOURCE,
_GNU_SOURCE or _BSD_SOURCE, or _SVID_SOURCE.
If CC is called with -std=c11, these macros won't be defined, Let's use
_flush_cache, which is defined always.
Reviewed By: brad, jrtc27
Differential Revision: https://reviews.llvm.org/D156072
(cherry picked from commit 0f99bc2d685c572c3b38fd0e1ca56be12d7e2f6a)
As detailed in Issue #57624, the introduction of
`__builtin_extract_return_address` to `GET_CALLER_PC` in
4248f32b9ebe87c7af8ee53911efd47c2652f488
<https://reviews.llvm.org/rG4248f32b9ebe87c7af8ee53911efd47c2652f488> broke
`TestCases/Misc/missing_return.cpp` on Solaris/SPARC. Unlike most other
targets, the builtin isn't a no-op on SPARC and thus has always been
necessary. Its lack had previously been worked around by calls to
`GetNextInstructionPc` in `sanitizer_stacktrace_sparc.cpp`
(`BufferedStackTrace::UnwindFast`) and `sanitizer_unwind_linux_libcdep.cpp`
(`BufferedStackTrace::UnwindSlow`). However, those calls are superfluous
now and actually harmful.
This patch removes those hacks, fixing the failure.
Tested on `sparcv9-sun-solaris2.11` and on `sparc-sun-solaris2.11` in the
GCC tree. On the latter, several more testcase failures had been caused by
this issue since ASan actually works with `gcc` on SPARC, unlike `clang`.
Differential Revision: https://reviews.llvm.org/D156504
(cherry picked from commit 679c076ae446af81eba81ce9b94203a273d4b88a)
Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
supported via EAX.
Intel documentation says invalid subleaves return 0. We had been
relying on that behavior instead of checking the max sublef number.
It appears that some Sandy Bridge CPUs return at least the subleaf 0
EDX value for subleaf 1. Best guess is that this is a bug in a
microcode patch since all of the bits we're seeing set in EDX were
introduced after Sandy Bridge was originally released.
This is causing avxvnniint16 to be incorrectly enabled with -march=native
on these CPUs.
Reviewed By: pengfei, anna
Differential Revision: https://reviews.llvm.org/D156963
(cherry picked from commit 2a5e3f4c6c2cdd2aab55fbfdb703ca8163351ea9)
Currently the *tf builtin functions can only be built if long double is an
IEEE float, which prevents them from being available e.g. for x86 targets
(unlike libgcc which has them). This non-functional change prepares the
builtins library *tf functions for being able to target x86 by decoupling
their presence from CRT_LDBL_128BIT and instead checking for a
CRT_HAS_TF_MODE macro. This change is NFC since the CRT_HAS_TF_MODE is
currently only set if long double is an IEEE 128-bit float.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D153812
This flag does nothing for clang and is apparently not supported by GCC:
aarch64-linux-gnu-gcc: error: unrecognized command-line option '-fnested-functions'; did you mean '-Wunused-function'?
It looks like it was maybe supported by Apple GCC, but that is no longer
a supported compiler.
Differential Revision: https://reviews.llvm.org/D153819
`PRE_READ` is called with a pointer and the size of the object
the pointer points to. But there is one line of code not calling
`PRE_READ` correctly(likely missing a dereference).
This patch fixes the problem.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154676
Commit 674a17e9bbe8 ("MIPS/compiler_rt: use synci to flush icache on
r6") completely removed the OS-specific guards under the guise of "For
pre-r6, we can use cacheflush libc function, which is same on Linux and
FreeBSD." However, the code in question had guards for Linux and
OpenBSD, not Linux and FreeBSD, and FreeBSD does not have a cacheflush
libc function as claimed, so this was neither the statement they
intended to make nor was it sufficient justification for making the code
completely unconditional. Whilst the upcoming FreeBSD 14 release has
dropped support for MIPS, FreeBSD 13 has support for it.
Fix this by only calling cacheflush on the OSes where it was previously
called, and not on other OSes where it either definitely isn't available
(FreeBSD) or is unknown (any other OS than the three mentioned in this
commit).
Modify the tests so that all clang warnings can be turned up to high.
Fix all places flagged by -Wconversion.
Fix a few unused variables not marked with UNUSED.
For the memtag testing, only compile some tests for 64 bit since
compiling them on 32 bit leads to warnings/errors. All of the tests
are already skipped on 32 bit OSes, so this will not affect any
real tests.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D155749
MSAN wrappers can be inserted for e.g. the access to stderr in the
constructor of the test, which can segfault if the constructor function
runs before these data structures have been initialized.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D155648
This was left in place to reduce the risk of breaking anything,
and to keep the diff smaller, in D155233.
Differential Revision: https://reviews.llvm.org/D155431
The test requires that an integer division by zero causes a trap, leading to a
signal like SIGFPE. This is the case on x86. On many other architectures, such
as Arm (unless software division is used and `__aeabi_idiv0` is patched),
Power, RISC-V, LoongArch, there is no trap. Therefore, it's more appropriate to
invert the condition to run the test.
Reviewed By: Ami-zhang
Differential Revision: https://reviews.llvm.org/D155644
A few memtag tests were using EXPECT_DEBUG_DEATH which executes the
statement unless NDEBUG is set. This meant the statement would
cause an abort, but the EXPECT_DEATH part was not done. Change these
to simply EXPECT_DEATH, these tests already verify that SCUDO_DEBUG
is set before checking for DEATH.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D155538
Before this patch when running HWASAN on x86_64 with with memory tagging support we got a bunch of false memory leak reports. The reason for that is that the heuristic used to detect if an 8 bytes could be a user pointer was not valid when memory tagging is used as the top byte could contain non-zero information.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D155338
The test fails on some builders but not on others; there's likely some
kind of environment dependence that should be investigated.
See https://reviews.llvm.org/D155317
The method cache stashes a mask in the high bits under some circumstances:
689525d556/runtime/objc-cache.mm (L589)
I'm hitting this now on macOS 13.4 arm64, so we can no longer rely on OBJC_FAST_IS_RW to identify potential pointers that need to be transformed
Differential Revision: https://reviews.llvm.org/D153471
XRayFileHeader storage was obtained from std::aligned_storage
using its default alignment and not the struct's alignment
requirement. This was causing a bus error on AArch32, on armv8
machines, where vld1.64/vst1.64 instructions with 128-bit
alignment requirement were being used to copy XRayFileHeader.
There is still another issue with fdr-single-thread.cpp test on
armv7. Now it runs until completion and produces a valid log file,
but for some reason the function name appears as _end in it,
instead of the expected mangled fn name.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155013
We are trying to build the compiler-rt as big-endian. And found that the tests compiler-rt/test/builtins/Unit/arm/aeabi_cdcmpeq_test.c and compiler-rt/test/builtins/Unit/arm/aeabi_cfcmpeq_test.c do not work on big endian at the moment. This patch makes these tests work on big endian as well.
Reviewed By: peter.smith, simon_tatham
Differential Revision: https://reviews.llvm.org/D155208
This makes the implicit conversion that is happening explicit.
Otherwise, each user is forced to suppress this
implicit-integer-sign-change runtime error in their their UBSAN
suppressions file.
For example, the runtime error might look like:
runtime error: implicit conversion from type 'long' of value -9223372036854775808 (64-bit, signed) to type 'uint64_t' (aka 'unsigned long') changed the value to 9223372036854775808 (64-bit, unsigned)
#0 0x55fe29dea91d in long FuzzedDataProvider::ConsumeIntegralInRange<long>(long, long) src/./test/fuzz/FuzzedDataProvider.h:233:25
[...]
SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change test/fuzz/FuzzedDataProvider.h:233:25 in
Differential Revision: https://reviews.llvm.org/D155206
With the new behaviour, the /MD or similar options aren't added to
e.g. CMAKE_CXX_FLAGS_RELEASE, but are added separately by CMake.
They can be changed by the cmake variable
CMAKE_MSVC_RUNTIME_LIBRARY or with the target property
MSVC_RUNTIME_LIBRARY.
LLVM has had its own custom CMake flags, e.g. LLVM_USE_CRT_RELEASE,
which affects which CRT is used for release mode builds. Deprecate
these and direct users to use CMAKE_MSVC_RUNTIME_LIBRARY directly
instead (and do a best effort attempt at setting CMAKE_MSVC_RUNTIME_LIBRARY
based on the existing LLVM_USE_CRT_ flags). This only handles the
simple cases, it doesn't handle multi-config generators with
different LLVM_USE_CRT_* variables for different configs though,
but that's probably fine - we should move over to the new upstream
CMake mechanism anyway, and push users towards that.
Change code in compiler-rt, that previously tried to override the
CRT choice to /MT, to set CMAKE_MSVC_RUNTIME_LIBRARY instead of
meddling in the old variables.
This resolves the policy issue in
https://github.com/llvm/llvm-project/issues/63286, and should
handle the issues that were observed originally when the
minimum CMake version was bumped, in
https://github.com/llvm/llvm-project/issues/62719 and
https://github.com/llvm/llvm-project/issues/62739.
Differential Revision: https://reviews.llvm.org/D155233
The patch fixes second argument of Function Multi Versioning resolvers,
it is pointer to an extendible struct containing hwcap and hwcap2 not a
unsigned long hwcap2. Also fixes FMV features caching in resolver.
Differential Revision: https://reviews.llvm.org/D155026
Currently if a program calls sigaction very early (before non-lazy sanitizer
initialization, in particular if .preinit_array initialization is not enabled),
then sigaction will wrongly fail since the interceptor is not initialized yet.
In all other interceptors we do lazy runtime initialization for this reason,
but we don't do it in the signal interceptors.
Do lazy runtime initialization in signal interceptors as well.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D155188
When enabling DriverKit, Address Sanitizer was unable to
intercept thread creation directly for dispatch workerthreads.
Because of this calls to GetStackTraceFromID failed and ASan was
unable to capture a meaningful stack trace.
This patch adds an interceptor for a dispatch function as a proxy
that is "close enough" to thread creation so that ASan is able
to meaningfully capture and register the dispatched thread.
Note: I propose not adding a test for this change.
Because this change is only meaningful in such a narrow usecase on Darwin
and is incredibly difficult to add a meaningful test.
Differential Revision: https://reviews.llvm.org/D154753
Unlike COMPILER_RT_HAS_CRT this handles the case where CRT is available
but has been disabled by setting COMPILER_RT_BUILD_CRT. This addresses
an issue reported on D153989.
Differential Revision: https://reviews.llvm.org/D155126
On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.
This is an alternative to D89492 and D136664.
Differential Revision: https://reviews.llvm.org/D153989
This test relies on MSVC style linking details, such as -Wl,-dll
(which could be expressed with just "-shared", which would work
with MinGW too) and an implicitly created import library named
"<basename>.lib" (which isn't created when linking in MinGW mode).
This fixes running the compiler-rt tests in MinGW environments.
We should merge two top TransferBatches so that the range marking can be
done correctly
This reverts commit 57ae8a2a1acb1aa1a5f55c29b1b338a780d649d5.
Differential Revision: https://reviews.llvm.org/D155009
Relanding with #if SANITIZER_GLIBC to avoid breaking FreeBSD.
Also incorporates Arthur's BUILD.gn fix (thanks!) from https://reviews.llvm.org/rGc1e283851772ba494113311405d48cfb883751d1
Original commit message:
This patch adds an msan interceptor for dladdr1 (with support for RTLD_DL_LINKMAP and RTLD_DL_SYMENT) and an accompanying test. It also adds a helper file, msan_dl.cpp, that contains UnpoisonDllAddrInfo (refactored out of the dladdr interceptor) and UnpoisonDllAddr1ExtraInfo.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D154272
