aboutsummaryrefslogtreecommitdiff
path: root/compiler-rt
AgeCommit message (Collapse)AuthorFilesLines
2024-04-15[RISCV] Support rv{32, 64}e in the compiler builtins (#88252)Cyrill Leutwiler2-0/+84
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)
2024-04-01[tsan] Refine fstat{,64} interceptors (#86625)Fangrui Song1-25/+18
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)
2024-03-27[msan] Re-exec with no ASLR if memory layout is incompatible on Linux (#85142)Thurston Dang3-14/+50
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)
2024-03-27[msan] Add 'MappingDesc::ALLOCATOR' type and check it is available (#85153)Thurston Dang3-13/+34
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)
2024-03-12Unbreak *tf builtins for hexfloat (#82208)Alexander Richardson4-19/+34
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)
2024-03-11[test] Make two sanitize-coverage tests pass with glibc 2.39+Fangrui Song2-2/+6
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)
2024-02-20[compiler-rt][profile] Fix InstrProfilingFile possible resource leak. (#81363)David CARLIER1-0/+3
close #79708 (cherry picked from commit 0a255fcf4a90f9e864ae9321b28e4956f7c865fb)
2024-02-18[AIX] Add a dummy variable in the __llvm_orderfile section (#81968)Wael Yehia2-1/+10
to satisfy the __start___llvm_orderfile reference when linking with -bexpfull and -fprofile-generate on AIX. (cherry picked from commit 15cccc55919d27eb2e89379a65f6c7809f679fda)
2024-02-09[dfsan] Wrap glibc 2.38 __isoc23_* functions (#79958)Fangrui Song3-155/+59
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)
2024-02-08[compiler-rt] remove hexdump interception. (#79378)David CARLIER3-39/+0
a freebsd dev member reported a symbol conflict and intercepting this had little value anyway. (cherry picked from commit 16a1ef86cbc5e6c829919ec6c73325413b0cd21b)
2024-02-06[Profile][Windows] Drop extern for __buildid. (#80700)Zequan Wu1-1/+1
(cherry picked from commit dd22140e21f2ef51cf031354966a3d41c191c6e7)
2024-02-05[compiler-rt] Remove duplicate MS names for chkstk symbols (#80450)Martin Storsjö2-4/+0
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)
2024-01-30[sanitizer] Handle Gentoo's libstdc++ pathSam James1-1/+3
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)
2024-01-23[NFCI] Move SANITIZER_WEAK_IMPORT to sanitizer_common (#79208)Chris Apple2-8/+8
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.
2024-01-23[NFC] Size and element numbers are often swapped when calling calloc (#79081)AtariDreams2-3/+3
gcc-14 will now throw a warning if size and elements are swapped.
2024-01-23[CompilerRT] Attempt to fix a lit-config issueJeremy Morse1-1/+1
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.
2024-01-23[AArch64][FMV] Support feature MOPS in Function Multi Versioning. (#78788)Alexandros Lamprineas3-0/+6
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.
2024-01-23[PGO] Remove calls to `__llvm_orderfile_dump()` in `instrprof-api.c` test ↵Qiongsi Wu1-7/+0
(#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.
2024-01-23Remove config.aarch64_sme from ↵Dinar Temirbulatov1-1/+0
compiler-rt/unittests/lit.common.unit.configured.in
2024-01-23[AArch64][compiler-rt] Add memcpy, memset, memmove, memchr builtins. (#77496)Dinar Temirbulatov8-5/+222
Add naive implementation of memcpy, memset, memmove, memchr for SME targets. Co-authored-by: David Sherwood <david.sherwood@arm.com>
2024-01-22Revert "[AArch64][compiler-rt] Add memcpy, memset, memmove, memchr builtins. ↵Douglas Yung7-220/+5
(#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
2024-01-22[AArch64][compiler-rt] Add memcpy, memset, memmove, memchr builtins. (#77496)Dinar Temirbulatov7-5/+220
Add naive implementation of memcpy, memset, memmove, memchr for SME targets. Co-authored-by: David Sherwood <david.sherwood@arm.com>
2024-01-23[tsan] Fix build for FreeBSD and NetBSD after 0784b1eefa36 (#79019)Dimitry Andric1-2/+4
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.
2024-01-22[PGO] Reland PGO's Counter Reset and File Dumping APIs #76471 (#78285)Qiongsi Wu5-50/+169
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.
2024-01-22[builtins][FMV][Apple] Use builtin atomic load/store, instead of libdispatch ↵Jon Roelofs1-13/+15
(#78807)
2024-01-22[asan,test] Make alloca_loop_unpoisoning.cpp robust and fix s390x failure ↵Fangrui Song1-3/+6
(#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.
2024-01-21[hwasan] Fix a possible null dereference problem (#77737)Wu Yingcong1-1/+1
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.
2024-01-19[fuzzer,test] Remove old debug loggingVitaly Buka1-1/+0
2024-01-19Reapply "[sanitizer] Skip /include/c++/ from summary (#78534)"Vitaly Buka2-1/+32
Keep linux only test. This reverts commit 4619147911c2a955bb605618bc518b45da994a81.
2024-01-19Re-exec TSan with no ASLR if memory layout is incompatible on Linux (#78351)Thurston Dang4-50/+138
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().
2024-01-19[builtins] Mark `int_lib.h` builtins as `static` (#69305)trevyn1-5/+5
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
2024-01-19Revert "[sanitizer] Skip /include/c++/ from summary (#78534)"Hans Wennborg2-19/+3
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.
2024-01-19[asan,test] Disable alloca_loop_unpoisoning.cpp on s390{{.*}}Fangrui Song1-0/+1
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).
2024-01-19[compiler-rt] Add a prefix on the windows mmap symbols (#78037)Martin Storsjö2-2/+7
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.
2024-01-18[dfsan] Don't clear shadow on dlopen(NULL, flags)Fangrui Song2-2/+2
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.
2024-01-18[sanitizer] Skip /include/c++/ from summary (#78534)Vitaly Buka2-3/+19
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.
2024-01-18[CompilerRT][ASan] Add new substitutions for tests while using lto to (#78523)Usama Hameed2-3/+13
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
2024-01-18[compiler-rt] making getrandom call blocking. (#78340)David CARLIER1-1/+7
except when `GRND_NONBLOCK` is present in the flags.
2024-01-18[X86] Support "f16c" and "avx512fp16" for __builtin_cpu_supports (#78384)Freddy Ye1-1/+4
This resolves issue #65320. This also supports clarify sapphirerapids and cooperlake for cpu_specific/dispatch.
2024-01-17[dfsan] Make sprintf interceptor compatible with glibc 2.37+ and musl (#78363)Fangrui Song3-9/+3
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
2024-01-17Remove maximum OSX version for sanitizers (#77543)Chris Apple1-5/+0
Remove a block preventing newer versions of the MacOS SDK from being selected for compiling the sanitizers.
2024-01-17[compiler-rt] On Windows, silence warning when building with latest MSVCAlexandre Ganea1-1/+1
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 ```
2024-01-17[compiler-rt][ORC] Silence warning when building on MSVC/WindowsAlexandre Ganea1-0/+1
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 ```
2024-01-17[compiler-rt] Fix fuzzer tests on WindowsAlexandre Ganea1-0/+10
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
2024-01-17[ORC-RT] Silence warning when building with Clang ToT on WindowsAlexandre Ganea1-1/+5
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. ```
2024-01-17[compiler-rt] Silence warnings when building with Clang ToTAlexandre Ganea3-0/+20
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. ```
2024-01-17[compiler-rt] Silence warning with MSVC 19.38 (Visual Studio 2022 17.8.3)Alexandre Ganea1-1/+7
This fixes: ``` C:\git\llvm-project\compiler-rt\lib\orc\coff_platform.cpp(512): warning C4189: 'JDState': local variable is initialized but not referenced ```
2024-01-16Sanitizer/MIPS: Use $t9 for preemptible function call (#76894)YunQiang Su2-2/+26
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>
2024-01-16[compiler-rt] Drop COMPILER_RT_BUILD_CRT workaround (#78331)Alexander Richardson1-5/+0
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.
2024-01-16[ASAN][sanitizers][win] Allow windows-asan to be built with /MDd and ↵Charlie Barto2-19/+21
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.
generated by cgit v1.1 at 2024-08-15 01:59:58 +0000