The fuzzer build was failing on armv7l, with an invalid triple
error. This happened because CMake's get_compiler_rt_target
function was missing some code to correctly handle arm archs,
such as armhf.
This was originaly part of https://reviews.llvm.org/D140011, that
landed on main with commit cd173cbd7cca69c29df42cd4b42e60433435c29b.
Fixes#60115
Differential Revision: https://reviews.llvm.org/D142906
The build of scudo was failing on armv7l, with undefined references
to unwinder symbols, such as __aeabi_unwind_cpp_pr0. These are
needed by RTGwpAsan and thus, on ARM, scudo must also be linked
against an unwind library.
The cmake command that caused the build failure was:
cmake --fresh -S "$PWD/llvm/" -B "$PWD/build/" -G Ninja \
-DCMAKE_INSTALL_PREFIX="$PWD/install" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;polly" \
-DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
-DLLVM_TOOLCHAIN_TOOLS="llvm-ar;llvm-ranlib;llvm-objdump;\
llvm-rc;llvm-cvtres;llvm-nm;llvm-strings;llvm-readobj;\
llvm-dlltool;llvm-pdbutil;llvm-objcopy;llvm-strip;llvm-cov;\
llvm-profdata;llvm-addr2line;llvm-symbolizer;llvm-windres;llvm-ml;\
llvm-readelf;llvm-size" \
-DLLVM_INSTALL_BINUTILS_SYMLINKS=OFF -DLLVM_PARALLEL_LINK_JOBS=1
Fixes#60115
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D142888
(cherry picked from commit e1e972689b9138db795885a5468a15aafbe7cb51)
Resetting oucp's stack to zero in swapcontext interception is incorrect,
since it breaks ucp cleanup after swapcontext returns in some cases:
Say we have two contexts, A and B, and we swapcontext from A to B, do
some work on Bs stack and then swapcontext back from B to A. At this
point shadow memory of Bs stack is in arbitrary state, but since we
can't know whether B will ever swapcontext-ed to again we clean up it's
shadow memory, because otherwise it remains poisoned and blows in
completely unrelated places when heap-allocated memory of Bs context
gets reused later (see https://github.com/llvm/llvm-project/issues/58633
for example). swapcontext prototype is swapcontext(ucontext* oucp,
ucontext* ucp), so in this example A is oucp and B is ucp, and i refer
to the process of cleaning up Bs shadow memory as ucp cleanup.
About how it breaks:
Take the same example with A and B: when we swapcontext back from B to A
the oucp parameter of swapcontext is actually B, and current trunk
resets its stack in a way that it becomes "uncleanupable" later. It
works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is
performed for Bs stack after B "returns" to A second time. That's
exactly what happens in the test i provided, and it's actually a pretty
common real world scenario.
Instead of resetting oucp's we make use of uc_stack.ss_flags to mark
context as "cleanup-able" by storing stack specific hash. It should be
safe since this field is not used in [get|make|swap]context functions
and is hopefully never meaningfully used in real-world scenarios (and i
haven't seen any).
Fixes https://github.com/llvm/llvm-project/issues/58633
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D137654
(cherry picked from commit b380e8b68951776656f286ecd079e2f30981905e)
When `llvm-symbolizer.exe` is on the PATH in an entry containing two
consecutive backslashes, sanitizers will try to launch llvm-symbolizer
with its absolute path containing these consecutive backslashes. This
fails a sanity check in `sanitizer_symbolizer_win.cpp`.
According to the documentation of `CommandLineToArgvW` [1] and a MS blog
post [2], backslashes in general, regardless of how many of them in a
row, do not have any special effect, unless when immediately followed by
a double quote.
There already exists a check that fails when the command line arguments
contains double quote, therefore the check for double backslashes can
simply be removed.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw
[2]: https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way
Differential Revision: https://reviews.llvm.org/D146621
(cherry picked from commit b1871ceb1cf6c6954380867d41db3812e9e0dbfc)
An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also
removed the #else clause for the error fallback, causing the build to
fail on NetBSD.
Differential Revision: https://reviews.llvm.org/D146316
(cherry picked from commit 8510cf9fc1a431b70737b2b046007d318c62b7a8)
Without the definition, build fails on AArch64 with
> error: 'AT_HWCAP2' undeclared (first use in this function);
> did you mean 'AT_HWCAP'?
with old Glibc versions.
Differential Revision: https://reviews.llvm.org/D145494
(cherry picked from commit 23fcca822a3a3b9a14b6a1ad432814e2634cdb63)
When building compiler-rt builtins for x86_64 they library will by default
also be built for i386. We unconditionally add the Float16 compile flags
since the check for Float16 support will be done using x86_64 compiler
flags, but i386 does not actually support it. Fix this by moving the
COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a
per-target-architecture check inside the loop (using
`check_c_source_compiles` and `cmake_{push,pop}_check_state`).
Many of the checks in the builtin-config-ix file should probably also be
changed to per-target-arch checks, but so far only the Float16 one has
caused issues. This is an alternative to D136044 which added a special case
for i386 FreeBSD.
Fixes: https://github.com/llvm/llvm-project/issues/57224
Differential Revision: https://reviews.llvm.org/D145237
(cherry picked from commit 489bda6a9c0ec9d2644b7bb0c230294d38f7296e)
Since binary ID lookup makes CLI object arguments optional, it should be
possible to pass a list of source files without a binary. Unfortunately,
the current syntax will always interpret the first source file as a
binary. This change adds a `-sources` option to cause all later
positional arguments to be considered sources.
Reviewed By: gulfem
Differential Revision: https://reviews.llvm.org/D144207
(cherry picked from commit 8007bcc13f8f5f5c352a24e122b7090494a62bfb)
The GetRssFromBuffer scudo test case fails intermittently on Power, so this test
is disabled on the platform because of this.
(cherry picked from commit 0e3ef5f89749a599c652c546214a8307e3495526)
If you are missing the iOS SDK on your macOS (for example you don't have
full Xcode but just CommandLineTools) then CMake currently errors
out without a helpful message. This patch disables iOS support in
compiler-rt if the iOS SDK is not found. This can be overriden by
passing -DCOMPILER_RT_ENABLE_IOS=ON.
Reviewed By: delcypher, thetruestblue
Differential Revision: https://reviews.llvm.org/D133273
(cherry picked from commit 78fb02107ae5819501af2600b0bebd48c1900a9b)
Without this, if hardening measures like FORTIFY_SOURCE are are in
/etc/clang/*.cfg, many sanitizer tests will die before the sanitizer
can trap the problem being tested, because e.g. the _chk variants
of common functions will abort first.
This gets the number of failing tests down from 42->3 for me (and the
remaining 3 are unrelated).
See: 52ce6776cf98e993c6ec04ae54b52e1354fff917
See: 136f77805fd89cd30e69b3d1204fbf7efedd9a12
Closes: https://github.com/llvm/llvm-project/issues/60394
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D143322
(cherry picked from commit 8ab762557fb057af1a3015211ee116a975027e78)
This patch remove xfail decorator from
builtins/Unit/trampoline_setup_test.c as it is passing on Windows/AArch64
nowz. It is being skipped in code with __clang__ not defined.
https://lab.llvm.org/buildbot/#/builders/120/builds/3873
Declare callbacks extern weak (if no existing declaration exists), and
only call if the function address is non-null.
This allows to attach semantic metadata to binaries where no user of
that metadata exists, avoiding to have to link empty stub callbacks.
Once the binary is linked (statically or dynamically) against a tool
runtime that implements the callbacks, the respective callbacks will be
called. This vastly simplifies gradual deployment of tools using the
metadata, esp. avoiding having to recompile large codebases with
different compiler flags (which negatively impacts compiler caches).
Reviewed By: dvyukov, vitalybuka
Differential Revision: https://reviews.llvm.org/D142408
This reverts commit 45368c75582f0bded1f06d5c82c1f2ee023fb186.
There were some unexpected failures in aarch64 and arm buildbots, I will
have to investigate why these suddenly fell over.
Since bfloat16 and float16 support is not available for i386-freebsd,
the `truncdfbf2.c` and `truncsfbf2.c` builtin sources should be skipped
when targeting that platform, and `COMPILER_RT_HAS_FLOAT16` should not
be defined.
However, the CMake configuration stage runs its tests with the default
target, which normally is amd64-freebsd, so it will detect both bfloat16
and float16 support.
Move adding of the `COMPILER_RT_HAS_FLOAT16` define to the `foreach()`
loop where all the supported architectures are handled, and do not
enable it when targeting i386-freebsd.
Also remove the bfloat16 sources from the `i386_SOURCES` list, when
targeting i386-freebsd.
Differential Revision: https://reviews.llvm.org/D136044
There are no intrinsic functions that leak arguments.
If the called function does not return, the current function
does not return as well, so no possibility of use-after-return.
Sanitizer function also don't leak or don't return.
It's safe to both pass pointers to local variables to them
and to tail-call them.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D142190
There are no intrinsic functions that leak arguments.
If the called function does not return, the current function
does not return as well, so no possibility of use-after-return.
Sanitizer function also don't leak or don't return.
It's safe to both pass pointers to local variables to them
and to tail-call them.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D142190
POSIX timer can be configured to send any kind of signal, however, it
fundamentally does not make sense to consider a timer a synchronous
signal. Teach TSan that timers are never synchronous.
The tricky bit here is correctly defining compiler-rt's siginfo
replacement, which is a rather complex struct. Extend it in a limited
way that is mostly cross-platform compatible and add offset tests in
sanitizer_platform_limits_posix.cpp.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D142117
In LLVM the MachOPlatform class is modified to identify unwind info sections
and the address ranges of the functions these sections cover. These address
ranges are then communicated to the ORC runtime by attaching them to the
register-object-platform-sections allocation action.
In the ORC runtime the unwind-info section addresses are recorded and used to
support lookup of unwind info via the new `findDynamicUnwindSections` function.
At bootstrap time the ORC runtime checks for the presence of new
unwind-info-lookup-registration functions in libunwind (see
https://reviews.llvm.org/D142176), and if available uses them to register the
`findDynamicUnwindSections` function with libunwind to enable callback-based
lookup. If the new unwind-info-lookup-registration functions are not available
then the ORC runtime falls back to using the existing libunwind registration
APIs.
The callback-based scheme is intended to address three shortcomings in the
current registration scheme for JIT'd unwind info on Darwin: (1) Lack of
compact-unwind support, (2) inability to describe the subarchitecture of JIT'd
frames, and (3) lack of efficient address-based lookup data structures in
libunwind.
For more details see the proposed libunwind changes in
https://reviews.llvm.org/D142176.
In many cases, we can use an alias to avoid a symbolic relocations,
instead of using the public, interposable symbol. When the instrumented
function is in a COMDAT, we can use a hidden alias, and still avoid
references to discarded sections.
Previous versions of this patch allowed the compiler to name the
generated alias, but that would only be valid when the functions were
local. Since the alias may be used across TUs we use a more
deterministic naming convention, and add a ".local" suffix to the alias
name just as we do for relative vtables aliases.
https://reviews.llvm.org/rG20894a478da224bdd69c91a22a5175b28bc08ed9
removed an incorrect assertion on Mach-O which caused assertion failures in LLD.
We addressed the link errors under ThinLTO + PGO + CFI by being more
selective about which comdat functions can be given aliases.
Specifically, we now do not emit an alias in the case of a comdat
function with hidden visibility, since the alias would have the same
linkage and visibility, giving no benefit over using the symbol
directly. This also prevents LowerTypeTest from incorrectly updating the
dangling alias after GlobalOpt replaces uses, and introducing a
duplicate symbol.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D137982
Lines with 'record_addr:' are not processed when failing to decode
access tag. The regular format is: %02x/%02x but for a short tag it's:
%02x/%02x(%02x). Now it will handle both cases.
Tested-by: Ivar Henckel <ivar.henckel@sony.com>
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D141906
Unlike asan, we can't use pointer arithmetics to get from user ptr to
metadata. Asan does not use CombinedAllocator::GetMetadata and store
metadata next to the user data.
