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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
Saleem Abdulrasool