aboutsummaryrefslogtreecommitdiff
path: root/libunwind
AgeCommit message (Collapse)AuthorFilesLines
2024-03-14[runtimes] Prefer -fvisibility-global-new-delete=force-hidden (#84917)Martin Storsjö1-1/+4
27ce26b06655cfece3d54b30e442ef93d3e78ac7 added the new option -fvisibility-global-new-delete=, where -fvisibility-global-new-delete=force-hidden is equivalent to the old option -fvisibility-global-new-delete-hidden. At the same time, the old option was deprecated. Test for and use the new option form first; if unsupported, try using the old form. This avoids warnings in the MinGW builds, if built with Clang 18 or newer. (cherry picked from commit 1f973efd335f34c75fcba1ccbe288fd5ece15a64)
2024-02-09MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521)YunQiang Su1-0/+19
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com> (cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
2024-01-16[libunwind] Move errno.h and signal.h includes under the block where they're ↵Louis Dionne1-2/+2
needed (#78054) Commit fc1c478709e3 added includes of <signal.h> and <errno.h> to UnwindCursor.hpp. The library previously built on platforms where these headers are not provided. These headers should be included only in the case where they are actually needed, i.e. on Linux.
2024-01-16[libunwind][WebAssembly] Fix libunwind.cpp guard (#78230)Heejin Ahn1-2/+2
This should have been `&&`, meaning neither SjLj nor Wasm uses this file.
2024-01-16[libunwind] fix dynamic .eh_frame registration (#77185)SihangZhu1-1/+1
Fix this issue [#76957](https://github.com/llvm/llvm-project/issues/76957) Libgcc provides __register_frame to register a dynamic .eh_frame section, while __unw_add_dynamic_eh_frame_section can be used to do the same in libunwind. However, the address after dynamic .eh_frame are padding with 0 value, it will be identified as legal CIE. And __unw_add_dynamic_eh_frame_section will continue to parse subsequent addresses until illegal memory or other sections are accessed. This patch adds length formal parameter for dynamic registration.
2024-01-10[libunwind] Convert a few options from CACHE PATH to CACHE STRING (#77534)Martin Storsjö1-4/+4
This applies the same change as in 760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi and libcxx) to libunwind as well. These options can reasonably be set either as an absolute or relative path, but if set as type PATH, they are rewritten from relative into absolute relative to the build directory, while the relative form is intended to be relative to the install prefix.
2024-01-09[libc++] Allow running the test suite with optimizations (#68753)Louis Dionne3-14/+36
This patch adds a configuration of the libc++ test suite that enables optimizations when building the tests. It also adds a new CI configuration to exercise this on a regular basis. This is added in the context of [1], which requires building with optimizations in order to hit the bug. [1]: https://github.com/llvm/llvm-project/issues/68552
2024-01-05[libunwind] Replace process_vm_readv with SYS_rt_sigprocmask (#74791)Jordan R AW1-27/+50
process_vm_readv is generally considered dangerous from a syscall perspective, and is frequently blanket banned in seccomp filters such as those in Chromium and ChromiumOS. We can get the same behaviour during the invalid PC address case with the raw SYS_rt_sigprocmask syscall. Testing to ensure that process_vm_readv does not appear, I ran the output of check-unwind on an ARM64 device under strace. Previously, bad_unwind_info in particular would use process_vm_readv, but with this commit, it now no longer uses it: ``` strace test/Output/bad_unwind_info.pass.cpp.dir/t.tmp.exe \ |& grep process_vm_readv ``` The libunwind unittests were also tested on ARM64 ChromeOS (Gentoo Linux) devices.
2023-12-19[libunwind] Bump to CXX_STANDARD 17 (#75986)Fangrui Song1-2/+2
libunwind uses C-style and low-level C++, so the language standard doesn't matter that much, but bumping to C++17 aligns with the rest of LLVM and enables some features that would cause pedantic warnings in C++11 (e.g. -Wc++17-attribute-extensions for [[fallthrough]]/ [[nodiscard]]/[[maybe_unused]]). (Contributors might use these features unaware of the pedantic warnings). Suggested-by: Christopher Di Bella <cjdb@google.com>
2023-12-19[libunwind] Use -nostdlib++ when linking libunwind (#75646)Louis Dionne1-9/+13
We shouldn't need to link against libc++ or libc++abi when building libunwind, since that would otherwise be a circular dependency.
2023-12-13[runtimes] Don't link against compiler-rt explicitly when we use -nostdlib++ ↵Louis Dionne1-1/+6
(#75089) When we use the -nostdlib++ flag, we don't need to explicitly link against compiler-rt, since the compiler already links against it by default. This simplifies the flags that we need to use when building with Clang and GCC, and opens the door to further simplifications since most platforms won't need to detect whether libgcc and libgcc_s are supported anymore. Furthermore, on platforms where -nostdlib++ is used, this patch prevents manually linking compiler-rt *before* other system libraries. For example, Apple platforms have several compiler-rt symbols defined in libSystem.dylib. If we manually link against compiler-rt, we end up overriding the default link order preferred by the compiler and potentially using the symbols from the clang-provided libclang_rt.a library instead of the system provided one. Note that we don't touch how libunwind links against compiler-rt when it builds the .so/.a because libunwind currently doesn't use -nodefaultlibs and we want to avoid rocking the boat too much. rdar://119506163
2023-11-29[libunwind][WebAssembly] Omit unused parts of libunwind.cpp for Wasm (#73196)Heejin Ahn1-2/+3
Wasm doesn't use most of that file; Wasm does not allow access of system registers and those functionalities are provided from the VM.
2023-11-29[libc++] Run picolibc tests with qemuMichael Platings2-2/+11
This patch actually runs the tests for picolibc behind an emulator, removing a few workarounds and increasing coverage. Differential Revision: https://reviews.llvm.org/D155521
2023-11-29[libc++] Add initial support for picolibcMichael Platings1-0/+33
Picolibc is a C Standard Library that is commonly used in embedded environments. This patch adds initial support for this configuration along with pre-commit CI. As of this patch, the test suite only builds the tests and nothing is run. A follow-up patch will make the test suite actually run the tests. Differential Revision: https://reviews.llvm.org/D154246
2023-11-17[runtimes][NFC] Remove trailing whitespaceLouis Dionne2-2/+2
2023-11-16Remove deprecated warning from cmake files (#72595)Tacet1-5/+0
`LIBCXXABI_SYSROOT`, `LIBCXXABI_TARGET_TRIPLE` and `LIBCXXABI_GCC_TOOLCHAIN` are not supported anymore. Based on the comment, the warning should be removed after branching for LLVM 15.
2023-11-15[libunwind] Remove unnecessary strcpy dependency (#72043)Michael Kenzel2-2/+2
libunwind uses a minimal set of necessary standard library functions, basically just `memset` and `memcpy`. There is a single use of `strcpy` to copy the bytes `"CLNGUNW"` into a `uint64_t` object. This is both an arguably odd use of the `strcpy` function as well as it unnecessarily widens the set of library functions that must be available to build libunwind, which can be an obstacle in baremetal scenarios. This change simply replaces this one `strcpy` with the more fundamental `memcpy`.
2023-11-15[libunwind] Fix an inconsistent indentation (NFC) (#72314)Heejin Ahn1-1/+1
2023-10-31[libc++][AIX] Add OS version to target tripleJake Egan2-1/+7
This will allow for configuring tests according to AIX version. Reviewed By: daltenty, #libc, Mordante Differential Revision: https://reviews.llvm.org/D149660
2023-10-24[libunwind][AIX] static_cast the value from getLR() to avoid the warning ↵xingxue-ibm1-1/+1
from -Wconversion (#69767) This PR adds `static_cast` to the value returned from `getLR()` in the AIX unwinder to avoid warning in case `-Wconversion` is specified to build in 32-bit mode.
2023-10-16[libunwind][AIX] Fix problem with stepping up from a leaf function when ↵Xing Xue4-34/+325
unwinding started in a signal handler Summary: The implementation of AIX unwinder gets the return address from the link area of the stack frame of a function and uses the return address to walk up functions. However, when unwinding starts from a signal handler and the function that raised the signal happens to be a leaf function and it does not have its own stack frame, the return address of the stack frame of the leaf function points to the caller of the function that calls the leaf function because the leaf function and its caller share the same stack frame. As a result, the caller of the leaf function is skipped. This patch fixes the problem by saving the LR value in sigcontext when the unwinder hits the signal handler trampoline frame and using it as the return address of the leaf function. The LR value from sigcontext is saved in the unwinding context slot for LR currently unused. Reviewed by: stephenpeckham Differential Revision: https://reviews.llvm.org/D158655
2023-10-11[libunwind] Avoid reading OOB for non-existent .eh_frame_hdr (#68815)Alexander Richardson1-0/+13
I was running the tests with baremetal picolibc which has a linker script that __eh_frame_start==__eh_frame_end (not equal to zero) in case there is no .eh_frame_hdr. I noticed that libunwind was trying to read nonsense data because it was printing messages such as `libunwind: unsupported .eh_frame_hdr version: 20 at https://github.com/llvm/llvm-project/commit/8000d308146ebf49cb364cb600e28a0a42e22c83` This change adds a ehHdr size check to avoid reading this out-of-bounds data and potentially crashing.
2023-10-11[libunwind] Fix wrong end argument passed to decodeEHHdr() (#68813)Alexander Richardson1-3/+4
All but one callsite were actually passing start+length arguments. This should not have any functional change since the end argument is almost always ignored. I noticed this while debugging some incorrect error messages being printed while running the testsuite baremetal (using binaries that did not have a valid eh_frame_hdr section): the tests print `libunwind: unsupported .eh_frame_hdr version: 20 at https://github.com/arichardson/upstream-llvm-project/commit/8000d308146ebf49cb364cb600e28a0a42e22c83` because libunwind is reading nonsense data for .eh_frame_hdr.
2023-10-04[runtimes] Fix parsing of LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS (#67691)Alexander Richardson1-14/+7
Since 78d649a417b48cb8a2ba2e755f0e7c8fb8b1bb83 the recommended way to pass an executor is to use the _TEST_PARAMS variable, which means we now pass more complicated value (including ones that may contain multiple `=`) as part of this variable. However, the `REGEX REPLACE` being used has greedy matches so everything up to the last = becomes part of the variable name which results in invalid syntax in the generated lit config file. This was noticed due to builder failures for those using the CrossWinToARMLinux.cmake cache file. --------- Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
2023-10-02[libunwind] Add Unwind-wasm.c to CMakeLists.txt (#67770)Heejin Ahn2-4/+7
This was missing when the file was added in https://github.com/llvm/llvm-project/commit/058222b2316615194c089f2bc68d11341f39d26e. Also reordered some headers to make LLVM CI and clang-format happy.
2023-09-29[libunwind] Fix a -Wextra-semi warningAlex Richardson1-2/+2
2023-09-28[libunwind][nfc] Avoid type warning of debug printf (#67390)Kazushi Marukawa1-4/+4
Change PRIu32 to PRIxPTR to avoid type warning of debug printf since VE uses 64 bits SjLj. I don't use PRIuPTR since the print message has 0x-prefix from the beginning. I also change related PRIuPTR to PRIxPTR since those uses 0x-prefix too.
2023-09-26[libc++][lit] Allow overriding the executor for tests (#66545)Alexander Richardson2-3/+5
This is useful when trying to run multiple tests with different arguments to the executor script. This is needed in my case since I do not know the correct ssh connection arguments when building libc++. The testing script I have spawns multiple QEMU instances that listen on a given port on localhost and runs lit with the --num-shards/--run-shard argument. In order to connect each shard to the right QEMU instances I need to customize the arguments passed to ssh.py (--extra-ssh-args and --extra-scp-args) but can't do this at configure time since the target port is only known when running the tests but not when calling CMake. This change allows me to pass `executor=ssh.py <args>` to lit once I know the right hostname/port for running the tests. This also deprecates the `LIB{CXX,CXXABI,UNWIND}_EXECUTOR` CMake variable as the same can be achieved by adding `executor=...` to the `LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS` variable.
2023-09-26Revert "[libunwind] Relax a REQUIRES on a test that passes on FreeBSD"Alex Richardson1-1/+1
While it worked for me locally, it appears to be failing on the FreeBSD 13 buildbot. This reverts commit ab7896231e176e52801702b7221bcac2f4ffbd59.
2023-09-25[libunwind] Clarify comment added in #67205Alex Richardson3-3/+3
See https://github.com/llvm/llvm-project/pull/67205#issuecomment-1734443684
2023-09-25[libunwind] Pass -Wl,--export-dynamic on all supported platforms (#67205)Alexander Richardson3-6/+9
I was trying to run the tests on FreeBSD and noticed that we weren't printing symbol names. It turns out this is because of the missing -Wl,--export-dynamic flag. Instead of hardcoding the name of the flag and only passing it for Linux hosts, use a pre-existing CMake variable instead. I was not aware of this flag, but it appears to have been supported for the past 16 years (with support for more platforms added later): https://gitlab.kitware.com/cmake/cmake/-/commit/66d1930f5674f08e09f455b3f0777f2de3e0717e
2023-09-24[libunwind][nfc] avoid prototype warning (#67250)Kazushi Marukawa1-1/+2
Avoid following prototype related warning. Unwind-sjlj.c:85:75: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
2023-09-22[libunwind] Relax a REQUIRES on a test that passes on FreeBSDAlex Richardson1-1/+1
2023-09-22[libunwind][WebAssembly] Support Wasm EHHeejin Ahn2-1/+122
This adds Wasm-specific libunwind port to support Wasm exception handling (https://github.com/WebAssembly/exception-handling). Wasm EH requires `__USING_WASM_EXCEPTIONS__` to be defined. This adds `Unwind-wasm.c`, which defines libunwind APIs for Wasm. This also adds a `thread_local` struct of type `_Unwind_LandingPadContext`, which serves as a medium for input/output data between the user code and the personality function. How all these work is explained in https://github.com/WebAssembly/tool-conventions/blob/main/EHScheme.md. (The doc is old and "You Shouldn't Prune Unreachable Resumes" section doesn't apply anymore, but otherwise it should be good) The bulk of these changes was added back in Mar 2020 in https://github.com/emscripten-core/emscripten/pull/10577 to emscripten repo and has been used ever since. Now we'd like to upstream this so that other toolchains that don't use emscripten libraries, e.g., WASI, can use this too. Companion patch: D158918 Reviewed By: dschuff, #libunwind, phosek Differential Revision: https://reviews.llvm.org/D158919
2023-09-21[runtimes] Fix link order of system librarires on Apple platforms (#66940)Louis Dionne1-3/+10
On Apple platforms, we always support the -nostdlib++ flag. Hence, it is not necessary to manually link against system libraries. In fact, doing so causes us to link against libSystem explicitly, which messes up with the order of libraries we should use. Indeed: Before patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF) =========================================================================== $ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib} lib/libc++.1.dylib: @rpath/libc++.1.dylib /usr/lib/libSystem.B.dylib @rpath/libc++abi.1.dylib lib/libc++abi.1.dylib: @rpath/libc++abi.1.dylib /usr/lib/libSystem.B.dylib lib/libunwind.1.dylib: @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib After patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF) =========================================================================== $ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib} lib/libc++.1.dylib: @rpath/libc++.1.dylib @rpath/libc++abi.1.dylib /usr/lib/libSystem.B.dylib lib/libc++abi.1.dylib: @rpath/libc++abi.1.dylib /usr/lib/libSystem.B.dylib lib/libunwind.1.dylib: @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib Before patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON) ======================================================================= $ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib} lib/libc++.1.dylib: @rpath/libc++.1.dylib /usr/lib/libSystem.B.dylib @rpath/libc++abi.1.dylib @rpath/libunwind.1.dylib lib/libc++abi.1.dylib: @rpath/libc++abi.1.dylib /usr/lib/libSystem.B.dylib @rpath/libunwind.1.dylib lib/libunwind.1.dylib: @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib After patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON) ====================================================================== $ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib} lib/libc++.1.dylib: @rpath/libc++.1.dylib @rpath/libc++abi.1.dylib @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib lib/libc++abi.1.dylib: @rpath/libc++abi.1.dylib @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib lib/libunwind.1.dylib: @rpath/libunwind.1.dylib /usr/lib/libSystem.B.dylib As we can see, libSystem appears before the just-built libraries before the patch, which causes the libunwind.dylib bundled in libSystem.dylib to be used instead of the just-built libunwind.dylib. We didn't notice the issue until recently when I tried to update the macOS CI builders to macOS 13.5, where it is necessary to use the right libunwind library (the exact reason still needs to be investigated).
2023-09-19[libunwind][AIX] Fix up TOC register if unw_getcontext is called from a ↵xingxue-ibm2-5/+26
different module (#66549) `unw_getcontext` saves the caller's registers in the context. However, if the caller of `unw_getcontext` is in a different module, the glue code of `unw_getcontext` sets the TOC register (r2) with the new TOC base and saves the original TOC register value in the stack frame. This causes the incorrect TOC value is used when the caller steps up frames, which fails libunwind LIT test case `unw_resume.pass.cpp`. This PR fixes the problem by using the original TOC register value saved in the stack if the caller is in a different module and enables `unw_resume.pass.cpp` on AIX.
2023-09-12[libunwind] Use __builtin_alloca to avoid missing includeReagan Bohan1-1/+1
Differential Revision: https://reviews.llvm.org/D149635
2023-09-06[libunwind] Haiku: Initial supportTrung Nguyen7-4/+43
Adds build support for Haiku. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D157866
2023-08-31[runtimes] Fix some duplicate word typosLouis Dionne3-3/+3
Those fixes were taken from https://reviews.llvm.org/D137338.
2023-08-31[libunwind][NFC] Fix whitespace in commentsLouis Dionne1-40/+40
2023-08-23Make _LIBUNWIND_SUPPORT_FRAME_APIS a build-time optionSterling Augustine2-4/+6
Previously this was based on target architecture, but that makes very little sense--frame API availability is generally for libgcc compatibility and that is dependent on runtime needs rather than target architecture. Default this to on, so as not to remove the apis from environments that already have them. The functions this macro protects are stubs for libgcc-compatibility. Today, libunwind as a drop-in replacement for libgcc_eh links on x86, x86_64, and powerpc, but not aarch64, which doesn't really make sense. As there is nothing architecture specific about these, they should be provided everywhere or nowhere. The target-specific protection goes all the way back to the original code contribution in 312fcd0e1cf14482b2ae8eee8234541dcc3bc2c4 from 2013, so the original reason is lost to history, and probably not relevant today. Differential Revision: https://reviews.llvm.org/D158011
2023-08-19MIPS: unwind, don't save/restore hi/lo for R6YunQiang Su4-2/+25
HI/LO registers have been removed in MIPSr6. Save and restore them only for pre-R6. We keep the memory space for the registers so that we can use the same register indexes for r6 and pre-r6. Fixes: #60682 Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D156283
2023-08-04[libc++][libunwind] Fixes to allow GCC 13 to compile libunwind/libc++abi/libc++Nikolas Klauser1-5/+0
These are changes to allow GCC 13 to successfully compile the runtimes stack. Reviewed By: ldionne, #libc, #libunwind, MaskRay Spies: MaskRay, zibi, SeanP, power-llvm-team, mstorsjo, arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D151387
2023-07-27[libunwind] Fix build with -Wunused-functionShoaib Meenai1-2/+5
https://reviews.llvm.org/D144252 removed -Wno-unused-function from the libunwind build, but we have an unused function when you're building for armv7 without assertions. Mark that function as possibly unused to avoid the warning, and mark the parameter as a const pointer while I'm here to make it clear that nothing is modified by a debugging function. Reviewed By: #libunwind, philnik Differential Revision: https://reviews.llvm.org/D156496
2023-07-19[libunwind] Fix build error on 32 bit Arm after -Wcast-qual was addedDavid Spickett1-1/+1
New warning was added in https://reviews.llvm.org/D153911 which caused: https://buildkite.com/llvm-project/libcxx-ci/builds/28407#01896b79-2a5e-4554-ac31-2abec5a8b281 ../../libunwind/src/UnwindLevel1-gcc-ext.c:172:47: error: cast from 'const unsigned int *' to 'unsigned int *' drops const qualifier [-Werror,-Wcast-qual] ex.pr_cache.ehtp = (_Unwind_EHT_Header *) unwindInfo; I don't see any reason there should be a const here in the first place, so just remove it. Reviewed By: #libunwind, michaelplatings, MaskRay Differential Revision: https://reviews.llvm.org/D155685
2023-06-29[libunwind] Add cached compile and link flags to libunwindmgrzywac2-0/+8
Add flags allowing to use compile flags and libraries provided in cache with libunwind. Similar flags are already present in libc++ and libc++abi CMakeLists files. Differential Revision: https://reviews.llvm.org/D150252
2023-06-05[libunwind] Removes CMake work-arounds.Mark de Wever1-8/+0
CMake older than 3.20.0 is no longer supported. This removes work-arounds for no longer supported versions. Reviewed By: #libunwind, mstorsjo Differential Revision: https://reviews.llvm.org/D152100
2023-05-27Reland "[CMake] Bumps minimum version to 3.20.0.Mark de Wever2-3/+2
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-25[NFC][Py Reformat] Reformat python files in libcxx/libcxxabiTobias Hieta2-68/+69
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black`. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Reviewed By: #libc, kwk, Mordante Differential Revision: https://reviews.llvm.org/D150763
2023-05-17Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Nico Weber2-2/+3
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c. Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards. Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C" This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559. Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump" This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
generated by cgit v1.1 at 2024-08-15 02:36:57 +0000