summaryrefslogtreecommitdiffstats
path: root/libunwind/src
Commit message (Collapse)AuthorAgeFilesLines
* 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)
* [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
* [libunwind][RISCV] Add 64-bit RISC-V supportSam Elliott2019-12-166-1/+448
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libunwind] Emit dependent libraries only when detected by CMakeMichał Górny2019-12-012-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Correctly update isSignalFrame when unwinding the stack via dwarf.Sterling Augustine2019-11-073-4/+14
| | | | | | | | | | | | | | | | | | 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-121-0/+4
| | | | | | | | | | 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-111-36/+49
| | | | | | | | | | | | | | | | | 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
* 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-201-1/+4
| | | | | | | | | | | | 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
* [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
* [runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek2019-05-302-2/+2
| | | | | | | | | 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
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-221-2/+2
| | | | | | | | | | | | | | | | | 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-162-1/+42
| | | | | | | | | | | | | | | | 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-132-2/+38
| | | | | | | | | | | 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-111-1/+1
| | | | | | | | 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
* [libunwind] Export the weak alias in Mach-OPetr Hosek2019-04-041-0/+1
| | | | | | | | | | This is not necessary for ELF since .globl and .weak are mutually exclusive, but is necessary for Mach-O otherwise the symbol isn't visible externally. Differential Revision: https://reviews.llvm.org/D60245 llvm-svn: 357671
* [libunwind] Export the unw_* symbols as weak symbolsPetr Hosek2019-04-0312-275/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libunwind defines the _Unwind_* ABI used by libc++abi. This ABI is a stable quasi-standard common between multiple implementations such as LLVM and GNU. The _U* symbol name space is also safely within the symbol name space that standard C & C++ reserve for the implementation. Futhermore, libunwind also defines several unw_* symbols, and references these from the _Unwind_* entry points so the standard/reserved part of the ABI is dependent on the unw_* part of the ABI. This is not OK for a C or C++ implementation. The unw_* symbols are reserved for C and extern "C" used by application code. This change renames each unw_* function to __unw* and adds a weak alias unw_* to keep the public <libunwind.h> ABI unchanged for backwards compatibility. Every reference to unw_* in the implementation has been changed to use __unw* so that if other unw_* definitions are in force because nothing uses <libunwind.h> in a particular program, no _Unwind* code path depends on any unw_* symbol. Furthemore, __unw_* symbols are hidden, which saves PLT overhead in the shared library case. In the future, we should cconsider untangling the unw_* API/ABI from the _Unwind_* API/ABI. The internal API backing the _Unwind_* ABI implementation should not rely on any nonstandard symbols not in the implementation-reserved name space. This would then allow separating the _Unwind_* API/ABI from unw_* entirely, but that's a more substantial change that's going to require more significant refactoring. Differential Revision: https://reviews.llvm.org/D59921 llvm-svn: 357640
* [libunwind] Do not share an object library to create the static/shared librariesPetr Hosek2019-04-031-37/+12
| | | | | | This change is similar to r356150, with the same motivation. llvm-svn: 357606
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-081-2/+2
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-081-2/+2
| | | | | | | | | | | | | | | 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> and include/ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59013 llvm-svn: 355665
* Provide a placement new definition for the SEH version of UnwindCursorMartin Storsjo2019-02-031-0/+4
| | | | | | This fixes compilation after SVN r352966 in SEH mode. llvm-svn: 353010
* [libunwind] Provide placement new definitionPetr Hosek2019-02-023-16/+16
| | | | | | | | | While Clang automatically generates the code for placement new, g++ doesn't do that so we need to provide our own definition. Differential Revision: https://reviews.llvm.org/D57455 llvm-svn: 352966
* [libunwind] Remove the remote unwinding supportPetr Hosek2019-02-022-219/+0
| | | | | | | | | | This is unfinished, unused and incomplete. This could be brought back in the future if there's a desire to build a more complete implementation, but at the moment it's just bitrotting. Differential Revision: https://reviews.llvm.org/D57252 llvm-svn: 352965
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352688
* Revert "[CMake] Use correct visibility for linked libraries in CMake"Petr Hosek2019-01-301-2/+2
| | | | | | This reverts commit r352654: this broke libcxx and sanitizer bots. llvm-svn: 352658
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352654
* [libunwind] Support building hermetic static libraryPetr Hosek2019-01-291-7/+34
| | | | | | | | | | | | | | | This is useful when the static libunwind library is being linked into shared libraries that may be used in with other shared libraries that use different unwinder. We want to avoid avoid exporting libunwind symbols in those cases. This achieved by a new CMake option which can be enabled by libunwind vendors as needed. The same CMake option has already been added to libc++ and libc++abi in D55404 and D56026. Differential Revision: https://reviews.llvm.org/D57107 llvm-svn: 352559
* Drop the dependency on <algorithm>, add placement new inlinePetr Hosek2019-01-294-12/+33
| | | | | | | | | | | | We haven't eliminated C++ library dependency altogether in D57251, UnwindCursor.hpp had an unused dependency on <algorithm> which was pulling in other C++ headers. Removing that dependency also revealed (correctly) that we need our own global placement new declaration. Now libunwind should be independent of the C++ library. Differential Revision: https://reviews.llvm.org/D57262 llvm-svn: 352553
* Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__Martin Storsjo2019-01-293-16/+16
| | | | | | | | | | | | | | | | | | | | | The existing typedef of unw_fpreg_t to uint64_t might work and be correct for the ARM_EHABI case, but for dwarf, some cases in e.g. DwarfInstructions.hpp convert between double and unw_fpreg_t. When converting implicitly between double and unw_fpreg_t (uint64_t), the values get interpreted as integers and converted to float and vice versa, while the correct thing would be to keep the same bit pattern. Avoid the whole issue by using the same definition of unw_fpreg_t as all other architectures, when using dwarf unwinding on ARM. Change assembler functions to take a void pointer instead of unw_fpreg_t pointer, to avoid having a different mangled symbol name depending on the actual value of this typedef. Differential Revision: https://reviews.llvm.org/D57001 llvm-svn: 352461
OpenPOWER on IntegriCloud