Age | Commit message (Collapse) | Author | Files | Lines |
|
Register spills (save/restore) in RISC-V embedded work differently
because there are less registers and different stack alignment.
[GCC equivalent
](https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/save-restore.S#L298C16-L336)
Follow up from #76777.
---------
Signed-off-by: xermicus <cyrill@parity.io>
(cherry picked from commit bd32aaa8c9ec2094f605315b3989adc2a567ca98)
|
|
In glibc versions before 2.33. `libc_nonshared.a` defines
`__fxstat/__fxstat64` but there is no `fstat/fstat64`. glibc 2.33 added
`fstat/fstat64` and obsoleted `__fxstat/__fxstat64`. Ports added after
2.33 do not provide `__fxstat/__fxstat64`, so our `fstat/fstat64`
interceptors using `__fxstat/__fxstat64` interceptors would lead to
runtime failures on such ports (LoongArch and certain RISC-V ports).
Similar to https://reviews.llvm.org/D118423, refine the conditions that
we define fstat{,64} interceptors. `fstat` is supported by musl/*BSD
while `fstat64` is glibc only.
(cherry picked from commit d5224b73ccd09a6759759791f58426b6acd4a2e2)
|
|
This ports the change from TSan
(https://github.com/llvm/llvm-project/commit/0784b1eefa36d4acbb0dacd2d18796e26313b6c5).
Testing notes: run 'sudo sysctl vm.mmap_rnd_bits=32; ninja check-msan'
before and after this patch.
N.B. aggressive ASLR may also cause the app to overlap with the
allocator region; for MSan, this was fixed in
https://github.com/llvm/llvm-project/commit/af2bf86a372cacf5f536bae06e2f2d3886eefb7b
(cherry picked from commit 58f7251820b14c93168726a24816d8a094599be5)
|
|
MSan divides the virtual address space into APP, INVALID, SHADOW and
ORIGIN memory. The allocator usually just steals a bit of the APP
address space: typically the bottom portion of the PIE binaries section,
which works because the Linux kernel maps from the top of the PIE
binaries section. However, if ASLR is very aggressive, the binary may
end up mapped in the same location where the allocator wants to live;
this results in a segfault.
This patch adds in a MappingDesc::ALLOCATOR type and enforces that the
memory range for the allocator is not occupied by anything else.
Since the allocator range information is not readily available in
msan.h, we duplicate the information from msan_allocator.cpp.
Note: aggressive ASLR can also lead to a different type of failure,
where the PIE binaries/libraries are mapped entirely outside of the
APP/ALLOCATOR sections; that will be addressed in a separate patch
(https://github.com/llvm/llvm-project/pull/85142).
(cherry picked from commit af2bf86a372cacf5f536bae06e2f2d3886eefb7b)
|
|
This re-lands cc0065a7d082f0bd322a538cf62cfaef1c8f89f8 in a way that
keeps existing targets working.
---------
Original commit message:
#68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support.
I added support for QUAD_PRECISION to use the native hex float long double representation.
---------
Co-authored-by: Sean Perry <perry@ca.ibm.com>
(cherry picked from commit 99c457dc2ef395872d7448c85609f6cb73a7f89b)
|
|
glibc 2.39 added `nonnull` attribute to most libio functions accepting a
`FILE*` parameter, including fprintf[1]. The -fsanitize=undefined mode
checks the argument to fprintf and has extra counters, not expected by
two tests. Specify -fno-sanitize=nonnull-attribute to make the two tests
pass.
Fix #82883
[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=64b1a44183a3094672ed304532bedb9acc707554
Pull Request: https://github.com/llvm/llvm-project/pull/84231
(cherry picked from commit c3acbf6bb06f9039f9850e18e0ae2f2adef63905)
|
|
close #79708
(cherry picked from commit 0a255fcf4a90f9e864ae9321b28e4956f7c865fb)
|
|
to satisfy the __start___llvm_orderfile reference when linking with
-bexpfull and -fprofile-generate on AIX.
(cherry picked from commit 15cccc55919d27eb2e89379a65f6c7809f679fda)
|
|
Fix #79283: `test/dfsan/custom.cpp` has undefined symbol linker errors
on glibc 2.38 due to lack of wrappers for `__isoc23_strtol` and
`__isoc23_scanf` family functions.
Implement these wrappers as aliases to existing wrappers, similar to
https://reviews.llvm.org/D158943 for other sanitizers.
`strtol` in a user program, whether or not `_ISOC2X_SOURCE` is defined,
uses the C23 semantics (`strtol("0b1", 0, 0)` => 1), when
`libclang_rt.dfsan.a` is built on glibc 2.38+.
(cherry picked from commit 648560062af8deb4e6478130deb1dd8fa62929a8)
|
|
a freebsd dev member reported a symbol conflict and intercepting this
had little value anyway.
(cherry picked from commit 16a1ef86cbc5e6c829919ec6c73325413b0cd21b)
|
|
(cherry picked from commit dd22140e21f2ef51cf031354966a3d41c191c6e7)
|
|
Prior to 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, the builtins library
contained two chkstk implementations for each of i386 and x86_64, one
that was used in mingw environments, and one unused (with a symbol name
not matching anything that is used anywhere). Some of the functions
additionally had other, also unused, aliases.
After cleaning this up in 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2, the
unused symbol names were removed.
At the same time, symbol aliases were added for the names as they are
used by MSVC; the functions are functionally equivalent, but have
different names between mingw and MSVC style environments.
By adding a symbol alias (so that one object file contains two different
symbols for the same function), users can run into problems with
duplicate definitions, if they themselves define one of the symbols (for
various reasons), but need to link in the other one.
This happens for Wine, which provides their own definition of
"__chkstk", but when built in mingw mode does need compiler-rt to
provide the mingw specific symbol names; see
https://github.com/mstorsjo/llvm-mingw/issues/397.
To avoid the issue, remove the extra MS style names. They weren't
entirely usable as such for MSVC style environments anyway, as
compiler-rt builtins don't build these object files at all, when built
in MSVC mode; thus, the effort to provide them for MSVC style
environments in 885d7b759b5c166c07c07f4c58c6e0ba110fb0c2 was a
half-hearted step towards that.
If we really do want to provide those functions (as an alternative to
the ones provided by MSVC itself), we should do it in a separate object
file (even if the function implementation is the same), so that users
who have a definition of one of them but need a definition of the other,
won't have conflicts.
Additionally, if we do want to provide them for MSVC, those files
actually should be built when building the builtins in MSVC mode as well
(see compiler-rt/lib/builtins/CMakeLists.txt).
If we do that, there's a risk that an MSVC style build ends up linking
in and preferring our implementation over the one provided by MSVC,
which would be suboptimal. Our implementation always probes the
requested amount of stack, while the MSVC one checks the amount of
allocated stack and only probes as much as really is needed.
In short - this reverts the situation to what it was in the 17.x release
series (except for unused functions that have been removed).
(cherry picked from commit 248aeac1ad2cf4f583490dd1312a5b448d2bb8cc)
|
|
On Gentoo, libc++ is indeed in /usr/include/c++/*, but libstdc++ is at
e.g. /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14.
Use '/include/g++' as it should be unique enough. Note that the omission of
a trailing slash is intentional to match g++-*.
See https://github.com/llvm/llvm-project/pull/78534#issuecomment-1904145839.
Reviewed by: mgorny
Closes: https://github.com/llvm/llvm-project/pull/79264
Signed-off-by: Sam James <sam@gentoo.org>
(cherry picked from commit e8f882f83acf30d9b4da8846bd26314139660430)
|
|
SANITIZER_WEAK_IMPORT is useful for any call that needs to be
conditionally linked in. This is currently used for the
tsan_dispatch_interceptors, but can be used for other calls introduced
in newer versions of MacOS. (such as `aligned_alloc` in this PR
https://github.com/llvm/llvm-project/pull/79198).
This PR moves the definition to a higher level so it can be used in
other sanitizers.
|
|
gcc-14 will now throw a warning if size and elements are swapped.
|
|
This is a follow-up to 3112578597c03 -- it looks like passing the added
cmake flag to pythonize_bool also appends "_PYBOOL" to the flag name, which
this lit config file is missing. This trips up builds such as:
https://lab.llvm.org/buildbot/#/builders/275/builds/3661
https://lab.llvm.org/buildbot/#/builders/184/builds/9811
Where COMPILER_RT_HAS_AARCH64_SME ends up expanding to nothing.
|
|
The patch adds support for FEAT_MOPS (Memory Copy and Memory Set
instructions) in Function Multi Versioning. The bits [19:16] of the
system register ID_AA64ISAR2_EL1 indicate whether FEAT_MOPS is
implemented in AArch64 state. This information is accessible via ELF
hwcaps.
|
|
(#79150)
https://github.com/llvm/llvm-project/pull/78285 added a test which calls
`__llvm_orderfile_dump()`, a functionality that is not supported on many
platforms. This PR removes the call to `__llvm_orderfile_dump()` to
avoid it failing on unsupported platforms, and turn on the test for
Windows, so we test the rest of the API that are supported.
|
|
compiler-rt/unittests/lit.common.unit.configured.in
|
|
Add naive implementation of memcpy, memset, memmove, memchr for SME
targets.
Co-authored-by: David Sherwood <david.sherwood@arm.com>
|
|
(#77496)"
This reverts commit 3ab8d2aac7bc2dd45dda3db0b8a71fd27eefb749.
This change is causing issues running lit tests on many bots including:
- https://lab.llvm.org/buildbot/#/builders/197/builds/12119
- https://lab.llvm.org/buildbot/#/builders/184/builds/9792
- https://lab.llvm.org/buildbot/#/builders/93/builds/18455
- https://lab.llvm.org/buildbot/#/builders/231/builds/19858
- https://lab.llvm.org/buildbot/#/builders/121/builds/38426
- https://lab.llvm.org/buildbot/#/builders/230/builds/23990
- https://lab.llvm.org/buildbot/#/builders/57/builds/32391
- https://lab.llvm.org/buildbot/#/builders/247/builds/13502
- https://lab.llvm.org/buildbot/#/builders/275/builds/3601
- https://lab.llvm.org/buildbot/#/builders/269/builds/4211
- https://lab.llvm.org/buildbot/#/builders/18/builds/14161
- https://lab.llvm.org/buildbot/#/builders/19/builds/23893
- https://lab.llvm.org/buildbot/#/builders/37/builds/30295
- https://lab.llvm.org/buildbot/#/builders/77/builds/33979
|
|
Add naive implementation of memcpy, memset, memmove, memchr for SME
targets.
Co-authored-by: David Sherwood <david.sherwood@arm.com>
|
|
In 0784b1eefa36 some code for re-execution was moved to
`ReExecIfNeeded()`, but also extended with a few Linux-only features.
This leads to compile errors on FreeBSD, or other non-Linux platforms:
compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:247:25: error: use of
undeclared identifier 'personality'
247 | int old_personality = personality(0xffffffff);
| ^
compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:249:54: error: use of
undeclared identifier 'ADDR_NO_RANDOMIZE'
249 | (old_personality != -1) && ((old_personality & ADDR_NO_RANDOMIZE)
== 0);
| ^
compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:281:46: error: use of
undeclared identifier 'ADDR_NO_RANDOMIZE'
281 | CHECK_NE(personality(old_personality | ADDR_NO_RANDOMIZE), -1);
| ^
Surround the affected part with a `#if SANITIZER_LINUX` block for now.
|
|
https://github.com/llvm/llvm-project/pull/76471 caused buildbot failures
on Windows. For more details, see
https://github.com/llvm/llvm-project/issues/77546.
This PR revises the test and relands
https://github.com/llvm/llvm-project/pull/76471.
|
|
(#78807)
|
|
(#78774)
In the test from https://reviews.llvm.org/D7098, `char array[len];` is
32-byte aligned on most targets whether it is instrumented or not
(optimized by StackSafetyAnalysis), due to the the used `*FrameLowering`
being `StackRealignable`.
However, when using `SystemZELFFrameLowering`, an un-instrumented
`char array[len];` is only 8-byte aligned.
Ensure `char array[len];` gets instrumented like what we did to
`alloca_vla_interact.cpp`, to make the test pass on s390x.
|
|
This is clearly a copy-paste mistake, fix it with this patch.
After checking the `local.function_name` is not null, it should check
the len for `local.function_name`, not `local.name`. And this could lead
to possible null dereference since the second
`internal_strlen(local.name)` does not guarantee `local.name` is not
null.
|
|
|
|
Keep linux only test.
This reverts commit 4619147911c2a955bb605618bc518b45da994a81.
|
|
TSan's shadow mappings only support 30-bits of ASLR entropy on x86
Linux, and it is not practical to support the maximum of 32-bits (due to pointer compression and the overhead of shadow mappings). Instead, this patch changes TSan to re-exec without ASLR if it encounters an
incompatible memory layout, as suggested by Dmitry in
https://github.com/google/sanitizers/issues/1716.
If ASLR is already disabled but the memory layout is still incompatible,
it will abort.
This patch involves a bit of refactoring, because the old code is:
1. InitializePlatformEarly()
2. InitializeAllocator()
3. InitializePlatform(): CheckAndProtect()
but it may already segfault during InitializeAllocator() if the memory
layout is incompatible, before we get a chance to check in
CheckAndProtect().
This patch adds CheckAndProtect() during InitializePlatformEarly(), before the allocator is initialized. Naturally, it is necessary to ensure that CheckAndProtect() does *not* allow the heap regions to be occupied here, hence we generalize CheckAndProtect() to optionally check the heap
regions. We keep the original behavior of CheckAndProtect() in InitializePlatform() as a last line of defense.
We need to be careful not to prematurely abort if ASLR is disabled but TSan was going to re-exec for other reasons (e.g., unlimited stack size); we implement this by moving all the re-exec logic into ReExecIfNeeded().
|
|
Mark the following symbols as `static` to prevent duplicate definitions:
`__builtin_ctz`
`__builtin_clz`
`__builtin_clzll`
`__builtin_sadd_overflow`
>Without these then all of these functions show up in all object files
which include int_lib.h on Windows. This'll help prevent duplicate
symbols by ensuring they're not exported.
See:
https://github.com/rust-lang/compiler-builtins/issues/167
https://reviews.llvm.org/D34599
|
|
The test fails on Darwin, see comment on the PR.
> std:: usually is not a cause of the bug.
>
> We now display
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
> ```
> instead of
>
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
> ```
>
> `/include/c++/` matches both libc++ and libstdc++ include paths.
This reverts commit ecd47811b755d13357085bcd7519a66d6c4d8e5c.
|
|
The test (from https://reviews.llvm.org/D7098) is about the interaction
of VLA and alloca where the VLA causes alloca to have the same address.
This is mostly about behavior checking and less about instrumentation
correctness, so I think it is fair to disable it for a platform that
does not work after StackSafetyAnalysis is enabled by default (#77210).
|
|
For Windows, the compiler-rt profile library contains a polyfill
reimplementation of the mmap family of functions.
Previously, the runtime library exposed those symbols like, "mmap", in
the user symbol namespace. This could cause misdetections by configure
scripts that check for the "mmap" function just by linking, without
including headers.
Add a prefix on the symbols, and make an undeclared function static.
This fixes such an issue reported at
https://github.com/mstorsjo/llvm-mingw/issues/390.
|
|
This ports msan https://reviews.llvm.org/D14795 to dfsan.
dfsan, like msan, clears shadow for globals in a newly opened DSO in
case the DSO occupies the address of a previously labeled/poisoned area.
The operation should not happen on the main executable.
In addition, for a DT_EXEC executable, l_addr is zero and will lead to a
null pointer dereference in ForEachMappedRegion.
|
|
std:: usually is not a cause of the bug.
We now display
```
SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
```
instead of
```
SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
```
`/include/c++/` matches both libc++ and libstdc++ include paths.
|
|
explicitly pass libLTO path. This fixes a failure in swift-ci where
libLTO was being picked from the system instead which was an older
version and caused issues.
rdar://117474861
|
|
except when `GRND_NONBLOCK` is present in the flags.
|
|
This resolves issue #65320.
This also supports clarify sapphirerapids and cooperlake for
cpu_specific/dispatch.
|
|
snprintf interceptors call `format_buffer` with `size==~0ul`, which
may eventually lead to `snprintf(s, n, "Hello world!")` where `s+n`
wraps around. Since glibc 2.37 (https://sourceware.org/PR30441), the
snprintf call does not write the last char. musl snprintf returns -1
with EOVERFLOW when `n > INT_MAX`.
Change `size` to INT_MAX to work with glibc 2.37+ and musl.
snprintf interceptors are not changed. It's user responsibility to not
cause a compatibility issue with libc implementations.
Fix #60678
|
|
Remove a block preventing newer versions of the MacOS SDK from being
selected for compiling the sanitizers.
|
|
This fixes:
```
[3334/7449] Building C object projects\compiler-rt\lib\builtins\CMakeFiles\clang_rt.builtins-x86_64.dir\extendsfdf2.c.obj
C:\git\llvm-project\compiler-rt\lib\builtins\fp_extend_impl.inc(63): warning C4018: '<': signed/unsigned mismatch
```
|
|
This fixes (the ORC lib already builds with exceptions disabled):
```
[5/11] Building CXX object projects\compiler-rt\lib\orc\CMakeFiles\RTOrc.x86_64.dir\dlfcn_wrapper.cpp.obj
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\vector(1619): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
```
|
|
This fixes a link-time mismatch between the clang_rt.fuzzer-x86_64.lib
and the fuzzer tests, which happen to build with -fsanitize=address.
See: https://learn.microsoft.com/en-us/cpp/sanitizers/error-container-overflow?view=msvc-170
|
|
This fixes several of these:
```
[3524/7446] Building CXX object projects\compiler-rt\lib\orc\CMakeFiles\RTOrc.x86_64.dir\dlfcn_wrapper.cpp.obj
In file included from C:\git\llvm-project\compiler-rt\lib\orc\dlfcn_wrapper.cpp:15:
C:\git\llvm-project\compiler-rt\lib\orc\wrapper_function_utils.h(299,27): warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
299 | if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
| ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
C:\git\llvm-project\compiler-rt\lib\orc\compiler.h(60,55): note: expanded from macro 'ORC_RT_UNLIKELY'
60 | #define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
| ^~~~
1 warning generated.
```
|
|
Fixes several warnings such as:
```
C:\git\llvm-project\compiler-rt\lib\profile\InstrProfilingFile.c(760,18): warning: cast from 'const char *' to 'void *' drops const qualifier [-Wcast-qual]
760 | free((void *)lprofCurFilename.FilenamePat);
| ^
3 warnings generated.
```
|
|
This fixes:
```
C:\git\llvm-project\compiler-rt\lib\orc\coff_platform.cpp(512): warning C4189: 'JDState': local variable is initialized but not referenced
```
|
|
Currently, almost all of the shared libraries of MIPS, rely on $t9
to get the address of current function, instead of PCREL instructions,
even on MIPSr6. So we have to set $t9 properly.
To get the address of preemptible function, we need the help of GOT.
MIPS/O32 has .cpload, which can help to generate 3 instructions to get GOT.
For __mips64, we can get GOT by:
lui $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
daddu $t8, $t8, $t9
daddiu $t8, $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
And then get the address of __interceptor_func, and jump to it
ld $t9, %got_disp(_interceptor" SANITIZER_STRINGIFY(func) ")($t8)
jr $t9
Fixes #74047
Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>
|
|
This variable was explicitly removed from the cache to ease transition
from existing build directories but that breaks passing
COMPILER_RT_BUILD_CRT=OFF on the command line. I was surprised to see
the CRT builds being run for my builtins-only build config (I noticed
because one of the tests was failing despite having `REQUIRES: crt`).
If I pass `-DCOMPILER_RT_BUILD_CRT=OFF` to cmake and add some prints
around the `unset` statement it shows the following:
```
-- before unset(): COMPILER_RT_BUILD_CRT=OFF
-- after unset: COMPILER_RT_BUILD_CRT=
-- after cmake_dependent_option COMPILER_RT_BUILD_CRT=ON
```
Drop this temporary workaround now that over 6 months have passed.
|
|
intercept functions from the debug runtimes. (#77840)
It turns out this works _mostly_ fine, even when mixing debug versions
of asan with programs built with the release runtime. Using /MT (or
/MTd) with a dynamically linked asan has never really worked that well,
and I am planning on opening a PR that will completely remove the
static-asan configuration for windows and make programs linked with the
static CRT/runtime work with the DLL version of asan. This is better
than the current situation because the static linked version of asan
doesn't work well on windows if there are multiple DLLs in the process
using it.
The check for building asan with only /MD or /MT has been removed. It
was in AsanDoesNotSupportStaticLinkage, but was checking for debug CRTs,
not static linkage. The kind of static linkage this function is supposed
to check for (on linux for example) doesn't really exist on windows.
Note: There is one outstanding issue with this approach, if you mix a
/MDd DLLs and /MD dlls in the same process then the "real" function
called by asan interceptors will be the same for calls from both
contexts, potentially screwing up things like errno. This only happens
if you mix /MD and /MDd in the same process, because otherwise asan
won't find functions from both runtimes to intercept. We are working on
a fix for this, and it mainly hits with the CRT functions exported from
both ucrtbase and ntdll.
This change is being upstreamed from Microsoft's fork.
|