summaryrefslogtreecommitdiffstats
path: root/libunwind/src/Unwind-seh.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [libunwind] Export the unw_* symbols as weak symbolsPetr Hosek2019-04-031-32/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Provide placement new definitionPetr Hosek2019-02-021-10/+9
| | | | | | | | | 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
* Drop the dependency on <algorithm>, add placement new inlinePetr Hosek2019-01-291-0/+4
| | | | | | | | | | | | 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
* Revert "[libunwind] Drop the dependency on <algorithm>, add placement new ↵Petr Hosek2019-01-281-4/+0
| | | | | | | | | inline" This reverts commit r352384: this broke on ARM as UnwindCursor.hpp still has some C++ library dependencies. llvm-svn: 352427
* [libunwind] Drop the dependency on <algorithm>, add placement new inlinePetr Hosek2019-01-281-0/+4
| | | | | | | | | | | | 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
* Silence warnings about unused parametersMartin Storsjo2019-01-221-0/+3
| | | | | | 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
* Fix warnings about printf format stringsMartin Storsjo2019-01-221-2/+7
| | | | | | | | | | 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
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | 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
* [SEH] Add initial support for AArch64Martin Storsjo2018-12-181-1/+17
| | | | | | | | | | | | | 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
* [SEH] Zero-initialize EXCEPTION_RECORD and UNWIND_HISTORY_TABLE before ↵Martin Storsjo2018-12-111-0/+2
| | | | | | | | calling RtlUnwindEx This fixes PR39935. llvm-svn: 348836
* Fix existing code for SEH on ARM to compile correctlyMartin Storsjo2018-08-311-1/+6
| | | | | | | | | | | | | | | | | | | | Even though SEH for ARM is incomplete, make what code already exists at least compile correctly. The _LIBUNWIND_CURSOR_SIZE wasn't correct. ARM (and AArch64) have a DISPATCHER_CONTEXT field named TargetPc instead of TargetIp. For the libunwind.h UNW_* constants, there is no UNW_ARM_PC, only UNW_ARM_IP. Don't use 'r' as loop variable when 'r' already is a Registers_arm member. Differential Revision: https://reviews.llvm.org/D51530 llvm-svn: 341217
* Add support for SEH unwinding on Windows.Charles Davis2018-08-301-0/+468
Summary: I've tested this implementation on x86-64 to ensure that it works. All `libc++abi` tests pass, as do all `libc++` exception-related tests. ARM still remains to be implemented (@compnerd?). Special thanks to KJK::Hyperion for his excellent series of articles on how EH works on x86-64 Windows. (Seriously, check it out. It's awesome.) I'm actually not sure if this should go in as is. I particularly don't like that I duplicated the UnwindCursor class for this special case. Reviewers: mstorsjo, rnk, compnerd, smeenai, javed.absar Subscribers: mgorny, kristof.beyls, christof, chrib, cfe-commits, compnerd, llvm-commits Differential Revision: https://reviews.llvm.org/D50564 llvm-svn: 341125
OpenPOWER on IntegriCloud