summaryrefslogtreecommitdiffstats
path: root/libunwind
Commit message (Collapse)AuthorAgeFilesLines
...
* [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-082-11/+6
| | | | | | | | 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-082-6/+11
| | | | | | | | | | | | | | | 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
* [CMake][libunwind] Define add_target_flags which is missingPetr Hosek2019-02-281-5/+11
| | | | | | | | It's use was introduced in r353084 but its definition is missing. Differential Revision: https://reviews.llvm.org/D58745 llvm-svn: 355142
* [CMake] Don't cache LLVM_MAIN_SRC_DIRPetr Hosek2019-02-131-1/+0
| | | | | | | | | If we're not in a standalone build, this variable should be already set, so there's no need to set it again or to cache it. Differential Revision: https://reviews.llvm.org/D57993 llvm-svn: 353915
* [CMake] Support compiler-rt builtins library in testsPetr Hosek2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | We're building tests with -nostdlib which means that we need to explicitly include the builtins library. When using libgcc (default) we can simply include -lgcc_s on the link line, but when using compiler-rt builtins we need a complete path to the builtins library. This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY, so we just need to pass that path to lit and if config.compiler_rt is true, link it to the test. Prior to this patch, running tests when compiler-rt is being used as the builtins library was broken as all tests would fail to link, but with this change running tests when compiler-rt bultins library is being used should be supported. Differential Revision: https://reviews.llvm.org/D56701 llvm-svn: 353208
* [CMake] Update lit test configurationPetr Hosek2019-02-052-7/+9
| | | | | | | | | There are several changes: - Don't stringify Pythonized bools (that's why we're Pythonizing them) - Support specifying target and sysroot via CMake variables - Use consistent spelling for --target, --sysroot, --gcc-toolchain llvm-svn: 353137
* [CMake] Support CMake variables for setting target, sysroot and toolchainPetr Hosek2019-02-042-7/+17
| | | | | | | | | | | | | | | | | | | | | | CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
* 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-023-245/+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-292-7/+37
| | | | | | | | | | | | | | | 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-295-34/+36
| | | | | | | | | | | | 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
* Adjust documentation for git migration.James Y Knight2019-01-292-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__Martin Storsjo2019-01-294-17/+17
| | | | | | | | | | | | | | | | | | | | | 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
* Revert "[libunwind] Drop the dependency on <algorithm>, add placement new ↵Petr Hosek2019-01-284-11/+27
| | | | | | | | | inline" This reverts commit r352384: this broke on ARM as UnwindCursor.hpp still has some C++ library dependencies. llvm-svn: 352427
* Revert "[CMake] Use __libc_start_main rather than fopen when checking for C ↵Petr Hosek2019-01-281-1/+1
| | | | | | | | | library" This reverts commit r352341: it broke the build on macOS which doesn't seem to provide __libc_start_main in its C library. llvm-svn: 352411
* [libunwind] Drop the dependency on <algorithm>, add placement new inlinePetr Hosek2019-01-284-27/+11
| | | | | | | | | | | | 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: 352384
* [CMake] Use __libc_start_main rather than fopen when checking for C libraryPetr Hosek2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | The check_library_exists CMake uses a custom symbol definition. This is a problem when checking for C library symbols because Clang recognizes many of them as builtins, and returns the -Wbuiltin-requires-header (or -Wincompatible-library-redeclaration) error. When building with -Werror which is the default, this causes the check_library_exists check fail making the build think that C library isn't available. To avoid this issue, we should use a symbol that isn't recognized by Clang and wouldn't cause the same issue. __libc_start_main seems like reasonable choice that fits the bill. Differential Revision: https://reviews.llvm.org/D57142 llvm-svn: 352341
* [libunwind] Use placement new to avoid dependency C++ libraryPetr Hosek2019-01-251-7/+10
| | | | | | | | | | The rest of libunwind already uses placement new, these are the only places where non-placement new is being used introducing undesirable C++ library dependency. Differential Revision: https://reviews.llvm.org/D57251 llvm-svn: 352245
* [libunwind] Don't abort if encoutering invalid .eh_frame_hdrPetr Hosek2019-01-242-8/+14
| | | | | | | | | | | | | | | Recent Linux kernel release has introduced a bug as part of the ORC rollout where the vDSO has a valid .eh_frame section, but it's missing the .eh_frame_hdr section and GNU_EH_FRAME segment has zero size. This causes libunwind to abort which breaks programs that use libunwind. The other unwinder implementation (libgcc, non-gnu) instead silently bail out unless being compiled as debug. This change modifies libunwind to use the same strategy. Differential Revision: https://reviews.llvm.org/D57081 llvm-svn: 352016
* Silence warnings about unused parametersMartin Storsjo2019-01-223-0/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D56984 llvm-svn: 351888
* Remove an unused variableMartin Storsjo2019-01-221-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D56985 llvm-svn: 351878
* Add casts to avoid warnings about implicit conversions losing precisionMartin Storsjo2019-01-221-4/+3
| | | | | | | | | | | | | | | | | | | | This fixes warnings like these: DwarfInstructions.hpp:85:25: warning: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm>::pint_t' (aka 'unsigned int') [-Wshorten-64-to-32] DwarfInstructions.hpp:88:25: warning: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_arm>::pint_t' (aka 'unsigned int') [-Wshorten-64-to-32] Differential Revision: https://reviews.llvm.org/D56983 llvm-svn: 351877
* Fix warnings about printf format stringsMartin Storsjo2019-01-222-47/+63
| | | | | | | | | | Either adjust the format string to use a more exact type, or add casts (for cases when printing pointers to structs/objects with a %p format specifier). Differential Revision: https://reviews.llvm.org/D56982 llvm-svn: 351876
* Enable LLVM_ENABLE_WARNINGS when building standalone out of treeMartin Storsjo2019-01-221-0/+2
| | | | | | | | | When built within the llvm runtimes directory, the runtimes CMakeLists.txt adds the same. Differential Revision: https://reviews.llvm.org/D56981 llvm-svn: 351875
* Fix typos throughout the license files that somehow I and my reviewersChandler Carruth2019-01-211-1/+1
| | | | | | | | | | | all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1928-112/+84
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* Install new LLVM license structure and new developer policy.Chandler Carruth2019-01-191-1/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 llvm-svn: 351631
* [SjLj] Don't use __declspec(thread) in MinGW modeMartin Storsjo2019-01-181-1/+1
| | | | | | | | | | | GCC and Clang in MinGW mode don't support __declspec(thread), which after expanding macros ends up as __attribute__((thread)). Use the GCC specific attribute __thread instead (the next one in the chain of alternatives). Differential Revision: https://reviews.llvm.org/D56905 llvm-svn: 351587
* Bump the trunk version to 9.0.0svnHans Wennborg2019-01-162-3/+3
| | | | llvm-svn: 351320
* Update year in license filesHans Wennborg2019-01-151-1/+1
| | | | | | | In last year's update (D48219) it was suggested that the release manager might want to do this, so here we go. llvm-svn: 351194
* [Sparc] Add Sparc V8 supportDaniel Cederman2019-01-1410-17/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds the register class implementation for Sparc. Adds support for DW_CFA_GNU_window_save. Adds save and restore context functionality. Adds getArch() function to each Registers_ class to be able to separate between DW_CFA_AARCH64_negate_ra_state and DW_CFA_GNU_window_save which are both represented by the same constant. On Sparc the return address is the address of the call instruction, so an offset needs to be added when returning to skip the call instruction and its delay slot. If the function returns a struct it is also necessary to skip one extra instruction on Sparc V8. Reviewers: jyknight, mclow.lists, mstorsjo, compnerd Reviewed By: jyknight, compnerd Subscribers: jgorbe, mgorny, christof, llvm-commits, fedor.sergeev, JDevlieghere, ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D55763 llvm-svn: 351044
* Revert "[Sparc] Add Sparc V8 support"Jorge Gorbe Moya2019-01-1010-325/+2
| | | | | | This reverts commit r350705. llvm-svn: 350787
* [Sparc] Add Sparc V8 supportDaniel Cederman2019-01-0910-2/+325
| | | | | | | | | | | | | | | | | | | | | | Summary: Adds the register class implementation for Sparc. Adds support for DW_CFA_GNU_window_save. Adds save and restore context functionality. On Sparc the return address is the address of the call instruction, so an offset needs to be added when returning to skip the call instruction and its delay slot. If the function returns a struct it is also necessary to skip one extra instruction. Reviewers: jyknight, mclow.lists, mstorsjo, compnerd Reviewed By: compnerd Subscribers: fedor.sergeev, JDevlieghere, ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D55763 llvm-svn: 350705
* [SEH] Add initial support for AArch64Martin Storsjo2018-12-183-2/+75
| | | | | | | | | | | | | This doesn't yet implement inspecting the .pdata/.xdata to find the LSDA pointer (in UnwindCursor::getInfoFromSEH), but normal C++ exception handling seems to run just fine without it. (The only place I can see where it's even referenced is in unwind_phase2_forced, and I can't find a codepath where libcxxabi would end up calling that.) Differential Revision: https://reviews.llvm.org/D55674 llvm-svn: 349532
* [AArch64][libunwind] Unwinding support for return address signing with B KeyLuke Cheeseman2018-12-172-3/+18
| | | | | | | | | | - Support for the case where the return address has been signed with the B key - When the B key is used, a 'B' character is present in the augmentation string of CIE associated with the FDE for the function. Differential Revision: https://reviews.llvm.org/D55704 llvm-svn: 349339
* [AArch64][libunwind] Unwinding support for return address signingLuke Cheeseman2018-12-145-2/+45
| | | | | | | | | | | | | | - Follow up to revision r342895 - gcc would not build libunwind with the earlier patch as the autia1716 instruction wasn't allowed to be assembled for pre armv8.3a targets - The autia1716 instruction lives in the hint space encodings so is a valid instruction for all armv8a targets - To work around this I have swapped out the autia1716 instruction for the hint instruction Differential Revision: https://reviews.llvm.org/D55700 llvm-svn: 349140
* Avoid code duplication in the SEH version of UnwindCursor::getRegisterName. NFC.Martin Storsjo2018-12-122-116/+10
| | | | | | | | This requires making Registers_*::getRegisterName static. Differential Revision: https://reviews.llvm.org/D55610 llvm-svn: 348981
* [cmake] Rename append_if to avoid collision with LLVMMichal Gorny2018-12-112-38/+38
| | | | | | | | | | | Rename the 'append_if' macro used in libunwind to 'unwind_append_if'. Otherwise, when used in a combined LLVM+libunwind build, it overrides the *incompatible* 'append_if' function from LLVM and breaks projects following libunwind, e.g. OpenMP. Differential Revision: https://reviews.llvm.org/D55476 llvm-svn: 348852
* [SEH] Zero-initialize EXCEPTION_RECORD and UNWIND_HISTORY_TABLE before ↵Martin Storsjo2018-12-111-0/+2
| | | | | | | | calling RtlUnwindEx This fixes PR39935. llvm-svn: 348836
* Don't export assembly functions when function visibility annotations are ↵Martin Storsjo2018-12-111-0/+4
| | | | | | | | | | disabled Patch by Peiyuan Song! Differential Revision: https://reviews.llvm.org/D55537 llvm-svn: 348832
* [CMake] Passthrough CFLAGS when checking the compiler-rt pathPetr Hosek2018-11-141-0/+3
| | | | | | | | | | This is needed when cross-compiling for a different target since CFLAGS may contain additional flags like -resource-dir which change the location in which compiler-rt builtins are found. Differential Revision: https://reviews.llvm.org/D54371 llvm-svn: 346820
* [CMake] Link to compiler-rt if LIBUNWIND_USE_COMPILER_RT is ON.Charles Davis2018-10-082-3/+14
| | | | | | | | | | | | | | | | | | Summary: If `-nodefaultlibs` is given, we weren't actually linking to it. This was true irrespective of passing `-rtlib=compiler-rt` (see previous patch). Now we explicitly link it to handle that case. I wonder if we should be linking these libraries only if we're using `-nodefaultlibs`... Reviewers: beanz Subscribers: dberris, mgorny, christof, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D51657 llvm-svn: 343990
* Reverting r342895Luke Cheeseman2018-09-245-43/+2
| | | | | | - The used builtins do not compile for pre arm v8.3a targets with gcc llvm-svn: 342901
OpenPOWER on IntegriCloud