summaryrefslogtreecommitdiffstats
path: root/libunwind
Commit message (Collapse)AuthorAgeFilesLines
* Bump version to 10.0.1Tom Stellard2020-04-131-1/+1
|
* Fix a -Wbitwise-conditional-parentheses warning in _LIBUNWIND_ARM_EHABI ↵Nico Weber2020-02-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libunwind builds ``` src/UnwindCursor.hpp:1344:51: error: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Werror,-Wbitwise-conditional-parentheses] _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ~~~~~~~~~~~ ^ src/UnwindCursor.hpp:1344:51: note: place parentheses around the '|' expression to silence this warning _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ^ ( ) src/UnwindCursor.hpp:1344:51: note: place parentheses around the '?:' expression to evaluate it first _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ^ ( ) ``` But `0 |` is a no-op for either of those two interpretations, so I think what was meant here was ``` _info.flags = (isSingleWordEHT ? 1 : 0) | (scope32 ? 0x2 : 0); // Use enum? ``` Previously, if `isSingleWordEHT` was set, bit 2 would never be set. Now it is. From what I can tell, the only thing that checks these bitmask is ProcessDescriptors in Unwind-EHABI.cpp, and that only cares about bit 1, so in practice this shouldn't have much of an effect. Differential Revision: https://reviews.llvm.org/D73890 (cherry picked from commit 221c5af4e4f4a504a4d1f352dd7b76d305e56a62)
* Drop git version suffixAaron Puchert2020-02-171-1/+1
| | | | | | | | | | | | | | Summary: Also fix the version for libcxxabi, which was stuck in the past. Reviewers: hans, mclow.lists Reviewed By: hans Subscribers: mgorny, christof, libcxx-commits, llvm-commits, ldionne Tags: #libc, #llvm Differential Revision: https://reviews.llvm.org/D74586
* [libunwind] Fix evaluating DWARF operation DW_OP_pickSteven Wu2019-12-181-1/+1
| | | | | | | | | | | | reg is unsigned type and used here for getting array element from the end by negating it. negation of unsigned can result in large number and array access with that index will result in segmentation fault. Fixes: https://bugs.llvm.org/show_bug.cgi?id=43872 Patched by: kamlesh kumar Differential Revision: https://reviews.llvm.org/D69893
* [unwind] Don't link libpthread and libdl on FuchsiaPetr Hosek2019-12-171-4/+9
| | | | This is a follow up to D71135.
* [libunwind][RISCV] Add 64-bit RISC-V supportSam Elliott2019-12-168-1/+530
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add unwinding support for 64-bit RISC-V. This is from the FreeBSD implementation with the following minor changes: - Renamed and renumbered DWARF registers to match the RISC-V ABI [1] - Use the ABI mneumonics in getRegisterName() instead of the exact register names - Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit ABI in the future. [1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md Patch by Mitchell Horne (mhorne) Reviewers: lenary, luismarques, compnerd, phosek Reviewed By: lenary, luismarques Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski, simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl, benna, lenary, s.egerton, luismarques, emaste, cfe-commits Differential Revision: https://reviews.llvm.org/D68362
* Reland "Enable `-funwind-tables` flag when building libunwind"Sergej Jaskiewicz2019-12-116-2/+47
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Relands https://reviews.llvm.org/D70815. The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively disabled the linking step in CMake checks. This broke some builds (see 938c70b86c7d2165f8c28d5700e9c1ac1263307e). Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY only when checking for presence of the `-funwind-tables` flag, and then set it back to the original value so it doesn't affect other checks. Reviewers: mstorsjo, jfb Subscribers: mgorny, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71117
* Revert "Enable `-funwind-tables` flag when building libunwind"Martin Storsjö2019-12-046-46/+2
| | | | | | | | | | | | | | | | | This reverts commit b3fdf33ba6aa7ef80621696f74aaf2f6f8e1d1de. This change broke building libunwind for Windows/MinGW, and broke on aspect of the CMake tests in libunwind in general. After set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), CMake skips the linking step in tests, but cmake/config-ix.cmake also does a few checks for functions in libraries (looking for whether -lc provides fopen and whether -ldl provides dladdr). As CMake only tests building a static library, these tests incorrectly succeed and CMake concludes "Looking for fopen in c - found" and "Looking for dladdr in dl - found", while building then fails at the end with errors about unable to find -lc and -ldl.
* Enable `-funwind-tables` flag when building libunwindSergej Jaskiewicz2019-12-046-2/+46
| | | | | | | | | | | | | | | | | | | | | Summary: Or, rather, don't accidentally forget to pass it. This is aimed to solve the problem discussed in [this thread](http://lists.llvm.org/pipermail/llvm-dev/2019-November/136890.html), and to fix [a year-old bug](https://bugs.llvm.org/show_bug.cgi?id=38468). TL;DR: when building libunwind for ARM Linux, we **need** libunwind to be built with the `-funwind-tables` flag, because, well ARM EHABI needs unwind info produced by this flag. Without the flag all the procedures in libunwind are marked `.cantunwind`, which causes all sorts of bad things. From `_Unwind_Backtrace` not working, to C++ exceptions not being caught (which is the aforementioned bug is about). Previously, this flag was not added because the CMake check `add_compile_flags_if_supported(-funwind-tables)` produced a false negative. Why? With this flag, the compiler generates calls to the `__aeabi_unwind_cpp_pr0` symbol, which is defined in libunwind itself and obviously is not available at configure time, before libunwind is built. This led to failure at link time during the CMake check. We handle this by disabling the linker for CMake checks in linbunwind. Also, this patch introduces a lit feature `libunwind-arm-ehabi`, which is used to mark the `signal_frame.pass.cpp` test as unsupported (as was advised by @miyuki in D70397). Reviewers: peter.smith, phosek, EricWF, compnerd, jroelofs, saugustine, miyuki, jfb Subscribers: mgorny, kristof.beyls, christof, libcxx-commits, miyuki Tags: #libc Differential Revision: https://reviews.llvm.org/D70815
* [libunwind] Emit dependent libraries only when detected by CMakeMichał Górny2019-12-013-3/+8
| | | | | | | | | | | | | | | | | | | 996e62eef75 added Linux-specific dependent libraries to libunwind sources. As a result, building libunwind with modern LLD on *BSD started failing due to trying to link libdl. Instead, add those libraries only if they were detected by CMake. While technically we could create a long list of systems that need -ldl and -lpthread, maintaining a duplicate list makes little sense when CMake needs to detect it for non-LLD systems anyway. Remove existing system exceptions since they should be covered by the CMake check anyway. Remove -D_LIBUNWIND_HAS_COMMENT_LIB_PRAGMA since it is no longer explicitly needed, if we make the library-specific defines dependent on presence of this pragma support. Differential Revision: https://reviews.llvm.org/D70868
* [libunwind] Adjust the signal_frame test for ArmMikhail Maltsev2019-11-191-1/+7
| | | | | | | | | | | | | | | | | | | | Summary: This patch adjusts the signal_frame.pass.cpp to pass on Arm targets: * When Arm EHABI is used the unwinder does not use DWARF, hence the DWARF-specific check unw_is_signal_frame() must be disabled. * Certain C libraries don't include EH tables, so the unwinder must not try to step out of main(). The patch moves the test code out of main() into a separate function to avoid this. Reviewers: saugustine, ostannard, phosek, jfb, mclow.lists Reviewed By: saugustine Subscribers: dexonsmith, aprantl, kristof.beyls, christof, libcxx-commits, pbarrio, labrinea Tags: #libc Differential Revision: https://reviews.llvm.org/D70397
* change LLVM_VERSION_SUFFIX default from svn to gitNick Desaulniers2019-11-111-1/+1
| | | | | | | | | | | | | | | | | Summary: Sayonara SVN! Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewers: tstellar, jyknight, lebedev.ri, smeenai, mgorny, hans, mclow.lists Reviewed By: mgorny, hans Subscribers: christof, libcxx-commits, llvm-commits, srhines Tags: #libc, #llvm Differential Revision: https://reviews.llvm.org/D70019
* Correctly update isSignalFrame when unwinding the stack via dwarf.Sterling Augustine2019-11-074-4/+39
| | | | | | | | | | | | | | | | | | A "signal frame" is a function or block of code where execution arrives via a signal or interrupt, rather than via a normal call instruction. In fact, a particular instruction is interrupted by the signal and needs to be restarted. Therefore, when the signal handler is complete, execution needs to return to the interrupted instruction, rather than the instruction immediately following the call instruction, as in a normal call. Stack unwinders need to know this to correctly unwind signal frames. Dwarf handily provides an "S" in the CIE augmentation string to describe this case, and the libunwind API provides various functions to for unwinders to determine it,. The llvm libunwind implementation correctly sets it's internal variable "isSignalFrame" when initializing an unwind context. However, upon stepping up the stack, the current implementation correctly reads the augmentation string and sets it in the CIE info (which it then discards), libunwind doesn't update it's internal unwind context data structure. This change fixes that, and provides compatibility with both the canonical libunwind and the libgcc implementation. Reviewers: jfb Subscribers: christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D69677
* unwind: restore the LINKER_LANGUAGESaleem Abdulrasool2019-11-061-0/+6
| | | | | | | | | | | Have CMake treat the unwind libraries as C libraries rather than C++. There is no C++ runtime dependency at runtime. This ensures that we do not accidentally end up with a link against the C++ runtime. We need to explicitly reset the implicitly linked libraries for C++ to ensure that we do not have CMake force the link against the C++ runtime. This adjustment should enable the NetBSD bots to be happy with this change.
* unwind: reflow some of the build rules (NFC)Saleem Abdulrasool2019-11-061-32/+16
| | | | | Reflow the CMake properties to take less vertical space. This just makes it easier to read. NFC.
* unwind: disable RTTI during the build of libunwindSaleem Abdulrasool2019-11-061-0/+10
| | | | | | | | | Disable the type information emission for libunwind. libunwind does not use `dynamic_cast`. This results in a smaller binary, and more importantly, avoids the dependency on libc++abi. This ensures that we have complete symbol resolution of symbols on ELF targets without linking to the C++ runtime support library. This change avoids the emission of a reference to `__si_class_type_info`.
* Revert "build: explicitly set the linker language for unwind"Saleem Abdulrasool2019-11-061-2/+0
| | | | | | This reverts commit 6db7a5cd7c800a588e94ce5c1ef24ae4d60ecdd3. This adversely impacted the NetBSD libc++ bot for some reason, reverting while investigating.
* build: explicitly set the linker language for unwindSaleem Abdulrasool2019-11-041-0/+2
| | | | | | The unwinder should not depend on libc++. In fact, we do not end up with a link against libc++ as we do not have a dependency on libc++ at runtime. This ensures that we link with `clang` rather than `clang++`.
* [libunwind] [Windows] Add a log message if EnumProcessModules failsMartin Storsjö2019-10-311-1/+5
| | | | Differential Revision: https://reviews.llvm.org/D69504
* [libunwind][Android] Fix findUnwindSections for ARM EHABI BionicRyan Prichard2019-10-182-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix the arm_section_length count. The meaning of the arm_section_length field changed from num-of-elements to num-of-bytes when the dl_unwind_find_exidx special case was removed (D30306 and D30681). The special case was restored in D39468, but that patch didn't account for the change in arm_section_length's meaning. That patch worked when it was applied to the NDK's fork of libunwind, because it never removed the special case in the first place, and the special case is probably disabled in the Android platform's copy of libunwind, because __ANDROID_API__ is greater than 21. Turn the dl_unwind_find_exidx special case on unconditionally for Bionic. Bionic's dl_unwind_find_exidx is much faster than using dl_iterate_phdr. (e.g. Bionic stores exidx info on an internal soinfo object.) Reviewers: thomasanderson, srhines, danalbert, ed, keith.walker.arm, mclow.lists, compnerd Reviewed By: srhines, danalbert Subscribers: srhines, kristof.beyls, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68972 llvm-svn: 375275
* [libunwind][Android] Improve workaround for PIE zero-dlpi_addr bugRyan Prichard2019-10-161-23/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The workaround added in https://reviews.llvm.org/rL299575 appears to be working around a bug in Android JB 4.1.x and 4.2.x (API 16 and 17). Starting in API 16, Android added support for PIE binaries, but the dynamic linker failed to initialize dlpi_addr to the address that the executable was loaded at. The bug was fixed in Android JB 4.3.x (API 18). Improve the true load bias calculation: * The code was assuming that the first segment would be the PT_PHDR segment. I think it's better to be explicit and search for PT_PHDR. (It will be almost as fast in practice.) * It's more correct to use p_vaddr rather than p_offset. If a PIE executable is linked with a non-zero image base (e.g. lld's -Wl,--image-base=xxxx), then we must use p_vaddr here. The "phdr->p_vaddr < image_base" condition seems unnecessary and maybe slightly wrong. If the OS were to load a binary at an address smaller than a vaddr in the binary, we would still want to do this workaround. The workaround is safe when the linker bug isn't present, because it should calculate an image_base equal to dlpi_addr. Note that with API 21 and up, this workaround should never activate for dynamically-linked objects, because non-PIE executables aren't allowed. Consolidate the fix into a single block of code that calculates the true image base, and make it clear that the fix no longer applies after API 18. See https://github.com/android/ndk/issues/505 for details. Reviewers: mclow.lists, srhines, danalbert, compnerd Reviewed By: compnerd Subscribers: srhines, krytarowski, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68971 llvm-svn: 374969
* [libunwind] Fix issues introduced in r374606Petr Hosek2019-10-122-2/+6
| | | | | | | | | | There are few differences in compile flags introduced in r374606 which are causing libcxx-libcxxabi-libunwind-armv8-linux to fail. This change should address all of those, I've compared the generated build file from before r374606 and with this change and the set of flags is the same modulo order. llvm-svn: 374624
* [libunwind] Refactor CMake flag checks to match libc++ and libc++abiPetr Hosek2019-10-114-132/+371
| | | | | | | | | | | | | | | | | libunwind was using its own set of macros/functions for flag checking which was similar but different from libc++ and libc++abi. This made it difficult to replicate the same checks across projects, in fact there were some checks that appear to have been copy & pasted from another project and that were broken in the standalone libunwind build. This change refactors flag checks to match libc++ and libc++abi using a copy of HandleLibunwindFlags.cmake which is derived from the versions used by the other projects. This also paves a road to deduplicating and unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and HandleLibcxxFlags.cmake post monorepo switch. Differential Revision: https://reviews.llvm.org/D68855 llvm-svn: 374606
* [libunwind] Adjust libunwind_01.pass.cpp test for ARM EHABIJohn Brawn2019-10-031-1/+1
| | | | | | | | | | | | ARM EHABI unwinding tables only store the start address of each function, so the last function is assumed to cover the entire address space after it. The test picks an address on the stack assuming that it's in no function, but because of the above it's actually resolved to the last function. Fix this by using address 0 instead. Differential Revision: https://reviews.llvm.org/D68387 llvm-svn: 373628
* Unwind: avoid warning about unused typedefSaleem Abdulrasool2019-09-201-3/+3
| | | | | | | | | | | | | | | Move the definition of Elf_Addr typedef to the only place it is used, to avoid: ``` llvm-project/libunwind/src/AddressSpace.hpp:501:28: warning: unused typedef 'Elf_Addr' [-Wunused-local-typedef] ``` when compiling for Android with _LIBUNWIND_ARM_EHABI defined and _LIBUNWIND_SUPPORT_DWARF_UNWIND not defined. Patch by Joel Klinghed! llvm-svn: 372427
* Unwind: prevent unw_get_proc_info from returning stale dataSaleem Abdulrasool2019-09-202-1/+25
| | | | | | | | | | | | If unwind info is not available at the current IP, unw_get_proc_info should return a zero-filled structure rather than the info of the previous IP. This change also makes unw_get_proc_info return UNW_ENOINFO instead of UNW_ESUCCESS. Patch by Amanieu d'Antras! llvm-svn: 372407
* unwind: remove a could of extraneous `else` (NFC)Saleem Abdulrasool2019-09-181-4/+2
| | | | | | Simplify `if return else return` by removing the unnecessary `else`. llvm-svn: 372233
* [runtimes] Don't depend on libpthread on AndroidYi Kong2019-07-222-2/+2
| | | | | | | | | | r362048 added support for ELF dependent libraries, but broke Android build since Android does not have libpthread. Remove the dependency on the Android build. Differential Revision: https://reviews.llvm.org/D65098 llvm-svn: 366734
* [libunwind][ARM] Fix types in _Unwind_VRS_Get.Mikhail Maltsev2019-07-221-2/+2
| | | | | | | | | This is a small fix for https://reviews.llvm.org/D64996. The types of w0 and w1 in _Unwind_VRS_Get must be uint64_t, not uint32_t. Committing as obvious. llvm-svn: 366701
* [libunwind][ARM] Fix loading FP registers on big-endian targetsMikhail Maltsev2019-07-191-2/+7
| | | | | | | | | | | | | | | | | | | | Summary: The function Unwind-EHABI.cpp:_Unwind_VRS_Pop loads the saved values of 64-bit FP registers as two 32-bit words because they might not be 8-byte aligned. Combining these words into a 64-bit value has to be done differently on big-endian platforms. Reviewers: ostannard, john.brawn, dmgreen Reviewed By: ostannard Subscribers: kristof.beyls, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D64996 llvm-svn: 366587
* Bump the trunk version to 10.0.0svnHans Wennborg2019-07-182-3/+3
| | | | | | and clear the release notes. llvm-svn: 366427
* [libunwind] Fix Unwind-EHABI.cpp:getByte on big-endian targetsMikhail Maltsev2019-07-091-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: The function getByte is dependent on endianness and the current behavior is incorrect on big-endian targets. This patch fixes the issue. Reviewers: phosek, ostannard, dmgreen, christof, chill Reviewed By: ostannard, chill Subscribers: chill, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D64402 llvm-svn: 365505
* [libunwind][AArch64] Fix libunwind::Registers_arm64::jumptoMikhail Maltsev2019-06-171-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The AArch64 version of the libunwind function which restores the CPU state and resumes execution is not interrupt-safe. It restores the target value of SP before loading the floating-point registers from the context struct, but that struct is allocated on the stack which is being deallocated. This means that if an interrupt occurs during this function, and uses a lot of stack space, it could overwrite the values about to be loaded into the floating-point registers. This patch fixes the issue. Patch by Oliver Stannard. Reviewers: phosek, chill Reviewed By: chill Subscribers: chill, javed.absar, kristof.beyls, christof, LukeCheeseman, pbarrio, olista01, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D63006 llvm-svn: 363545
* [Docs] Modernize references to macOSJ. Ryan Stinnett2019-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This updates all places in documentation that refer to "Mac OS X", "OS X", etc. to instead use the modern name "macOS" when no specific version number is mentioned. If a specific version is mentioned, this attempts to use the OS name at the time of that version: * Mac OS X for 10.0 - 10.7 * OS X for 10.8 - 10.11 * macOS for 10.12 - present Reviewers: JDevlieghere Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits Tags: #clang, #lldb, #libc, #llvm Differential Revision: https://reviews.llvm.org/D62654 llvm-svn: 362113
* [CMake] Use find_package(LLVM) instead of LLVMConfigPetr Hosek2019-05-301-1/+1
| | | | | | | | This addresses an issues introduced in r362047. Differential Revision: https://reviews.llvm.org/D62640 llvm-svn: 362065
* [runtimes] Use -Wunknown-pragmas for the pragma checkPetr Hosek2019-05-301-0/+4
| | | | | | | This is a follow up to r362055, we need -Wunknown-pragmas otherwise the check is going to succeed it the pragma isn't supported. llvm-svn: 362057
* [runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek2019-05-304-4/+15
| | | | | | | | | This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
* [runtimes] Support ELF dependent libraries featurePetr Hosek2019-05-302-0/+6
| | | | | | | | | | | | | | | | | | | As of r360984, LLD supports dependent libraries feature for ELF. libunwind, libc++abi and libc++ have library dependencies: libdl librt and libpthread, which means that when libunwind and libc++ are being statically linked (using -static-libstdc++ flag), user has to manually specify -ldl -lpthread which is onerous. This change includes the lib pragma to specify the library dependencies directly in the source that uses those libraries. This doesn't make any difference when using linkers that don't support dependent libraries. However, when using LLD that has dependent libraries feature, users no longer have to manually specifying library dependencies when using static linking, linker will pick the library automatically. Differential Revision: https://reviews.llvm.org/D62090 llvm-svn: 362048
* [libunwind] [test] Fix inferring source pathsMichal Gorny2019-05-291-6/+4
| | | | | | | | | | | | | | | | | | | | | | Fix two issues that caused libcxx source path not to be inferred correctly when not specified explicitly: 1. get_lit_conf() uses default value only if the lit variable is set to None. Due to the mehod of substituting lit.site.cfg, they were "" rather than None when unset, effectively causing the default never to apply. Instead, use 'or' construct to use the default whenever get_lit_conf() returns a false value. 2. If os.path.join() is given a component starting with '/', it takes it to be an absolute path and ignores everything preceding it. Remove the slash to correctly append subdirectory. With these two fixes, libunwind tests start working on NetBSD buildbot again. Differential Revision: https://reviews.llvm.org/D62005 llvm-svn: 361931
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-222-6/+11
| | | | | | | | | | | | | | | | | include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
* [PPC] Fix 32-bit build of libunwindMartin Storsjo2019-05-163-256/+254
| | | | | | | | | | | | | | | Clang integrated assembler was unable to build libunwind PPC32 assembly code, present in functions used to save/restore register context. This change consists in replacing the assembly style used in libunwind source, to one that is compatible with both Clang integrated assembler as well as GNU assembler. Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D61792 llvm-svn: 360862
* [PPC64][libunwind] Fix r2 not properly restoredMartin Storsjo2019-05-163-1/+45
| | | | | | | | | | | | | | | | This change makes each unwind step inspect the instruction at the return address and, if needed, read r2 from its saved location and modify the context appropriately. The unwind logic is able to handle both ELFv1 and ELFv2 stacks. Reported by Bug 41050 Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D59694 llvm-svn: 360861
* Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to forceSterling Augustine2019-05-133-2/+39
| | | | | | | | | | | calls into the pthread library use weak symbols. This option allows libpthread to be a weak dependency rather than a hard one. Differential Revision: https://reviews.llvm.org/D60285 llvm-svn: 360610
* [gn] Support for building libunwindPetr Hosek2019-05-021-6/+11
| | | | | | | | | | | | This change introduces support for building libuwind. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D60370 llvm-svn: 359804
* [NFC] Fix typo in debug logLouis Dionne2019-04-221-1/+1
| | | | llvm-svn: 358896
* Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)Martin Storsjo2019-04-182-0/+6
| | | | | | | | Patch by Jérémie Faucher-Goulet! Differential Revision: https://reviews.llvm.org/D60417 llvm-svn: 358642
* [NFC] Move the export attribute after extern "C".Nicolas Lesser2019-04-121-8/+7
| | | | | | | Not all compilers support attributes before `extern "C"`. gcc is the main one that doesn't support it. llvm-svn: 358301
* [NFC] Correct outdated links to the Itanium C++ ABI documentationLouis Dionne2019-04-112-2/+2
| | | | | | | | Those are now hosted on GitHub. rdar://problem/36557462 llvm-svn: 358191
* [libunwind] Fix the typo in unw_save_vfp_as_X aliasPetr Hosek2019-04-111-1/+1
| | | | | | This was accidentaly introduced in r357640. llvm-svn: 358164
* Move the alias definition of unw_getcontext to within ↵Martin Storsjo2019-04-041-1/+2
| | | | | | | | | | | | !defined(__USING_SJLJ_EXCEPTIONS__) For builds with SJLJ, there is no __unw_getcontext symbol. On Windows, the weak alias macro also expands to a dllexport directive, which fails if the symbol doesn't exist. Differential Revision: https://reviews.llvm.org/D60251 llvm-svn: 357711
OpenPOWER on IntegriCloud