tree 66d5e689b12d7705ec57592872ba638b355ba307
parent 5cdb6a2a34aaa8f3fae95a4db1ec3f5be758746a
author Petr Hosek <phosek@chromium.org> 1554328203 +0000
committer Petr Hosek <phosek@chromium.org> 1554328203 +0000

[libunwind] Export the unw_* symbols as weak symbols

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@357640 91177308-0d34-0410-b5e6-96231b3b80d8