Commit Graph

567 Commits

Author SHA1 Message Date
Brandon Bergren bb13411614 [libunwind] Multiple preprocessor fixes on PowerPC*
* Remove misnamed `PPC64_HAS_VMX` in preference of directly checking `defined(__VSX__)`.

libunwind was using "VMX" to mean "VSX". "VMX" is just another name for Altivec, while "VSX" is the vector-scalar extensions first used in POWER7. Exposing a "PPC64_HAS_VMX" define was misleading and incorrect.

* Add `defined(__ALTIVEC__)` guards around vector register operations to fix non-altivec CPUS such as the e5500.

When compiling for certain Book-E processors such as the e5500, we want to skip vector save/restore, as the Altivec registers are illegal on non-Altivec implementations.

* Add `!defined(__NO_FPRS__)` guards around traditional floating-point save/restore.

When compiling for powerpcspe, we cannot access floating point registers, as there aren't any. (The SPE on e500v2 is a 64-bit extension of the GPRs, and it doesn't have the normal floating-point registers at all.)
This fixes building for powerpcspe, although no actual handling for SPE save/restore is written yet.

Reviewed By: MaskRay, #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D91906
2020-11-23 19:07:21 -08:00
Fangrui Song 3324fd8a7b [libunwind] Delete unused handlerNotFound in unwind_phase1 2020-11-21 12:38:00 -08:00
Daniel Kiss e7b8d3776f [libunwind] LIBUNWIND_REMEMBER_HEAP_ALLOC to cmake.
Missed it originally in https://reviews.llvm.org/D85005.

Reviewed By: gargaroff

Differential Revision: https://reviews.llvm.org/D91182
2020-11-11 11:21:17 +01:00
Louis Dionne 8d51969bd4 [runtimes] Avoid overwriting the rpath unconditionally
When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).

llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.

This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.

This is a revert of the following commits:

  libunwind: 3a667b9bd8
  libc++abi: 4877063e19
  libc++: 88434fe05f

Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.

Differential Revision: https://reviews.llvm.org/D91099
2020-11-09 16:56:03 -05:00
Fangrui Song 2c481f128c [libunwind] Delete unused codeOffsetAtStackDecrement/registersInOtherRegisters/sameValueUsed
ld64 uses them to create compact unwind from DWARF call frame information.
When the code was ported to libunwind, the variables were not deleted.

Reviewed By: #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D91039
2020-11-09 10:19:12 -08:00
Louis Dionne c1887e3f15 Revert "Allow running back-deployment testing against libc++abi"
This reverts commit 4d79ef814a, which broke a few build bots.
I'm reverting until I have time to investigate.
2020-11-06 17:26:42 -05:00
Louis Dionne 4d79ef814a Allow running back-deployment testing against libc++abi
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.

Also, add XFAIL markup to flag expected errors.
2020-11-06 08:12:46 -05:00
Daniel Kiss 1d7786d45f [libunwind] Support DW_CFA_remember/restore_state without heap allocation.
This patch just reorganises the code to make possible to use alloca
instead of malloc. This makes possible to use `.cfi_remember_state`/`.cfi_restore_state` on
platforms without heap allocation.
Also it will be safe to backtrace/unwind faults related to the allocator behind malloc.
`_LIBUNWIND_REMEMBER_HEAP_ALLOC ` option reenables the heap usage for `.cfi_remember_state`/`.cfi_restore_state`.
Define _LIBUNWIND_REMEMBER_STACK_ALLOC to force stack allocation.

Reviewed By: #libunwind, mstorsjo

Differential Revision: https://reviews.llvm.org/D85005
2020-10-30 17:45:20 +01:00
Daniel Kiss 05598e3d30 [libunwind] Fix linker flag handling in the tests.
--export-dynamic is not always available on all targets.
-funwind-tables was a duplicate in the lit.site.cfg.in.

Reviewed By: ldionne

Differential Revision: https://reviews.llvm.org/D90202
2020-10-29 14:02:44 +01:00
Martin Storsjö df6d2e8ab1 [libunwind] Add -Wno-dll-attribute-on-redeclaration when building for windows
It's not worth trying to fix these warnings within libunwind, instead
silence them.

Differential Revision: https://reviews.llvm.org/D90075
2020-10-26 23:23:01 +02:00
Louis Dionne 48e4b0fd3a [runtimes] Revert the libc++ __config_site change
This is a massive revert of the following commits (from most revent to oldest):

	2b9b7b5775.
	529ac33197
	28270234f1
	69c2087283
	b5aa67446e
	5d796645d6

After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.

These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.

See https://reviews.llvm.org/D89041 for more details on this adventure.
2020-10-23 09:41:48 -04:00
Louis Dionne 5d796645d6 [take 2] [libc++] Include <__config_site> from <__config>
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.

This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.

It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.

This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.

Differential Revision: https://reviews.llvm.org/D89041
2020-10-21 10:40:33 -04:00
Dominik Montada 8c03fdf34a [libcxxabi,libunwind] support running tests in standalone mode
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.

Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.

Reviewed By: ldionne, #libc_abi, #libc

Differential Revision: https://reviews.llvm.org/D86540
2020-10-14 09:10:20 +02:00
Raphael Isemann 6b7a49bb43 Fix all the CMake code that can only handle -stdlib= but not --stdlib=
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).

This just adds the alternative spelling before the`-stdlib=` variant in all
these places

Reviewed By: ldionne

Differential Revision: https://reviews.llvm.org/D87133
2020-10-13 16:05:21 +02:00
Martin Storsjö fc5e68fab9 [libunwind] [SEH] Don't interact with foreign exceptions
This unfortunately means that we don't execute C++ destructors when
unwinding past such frames for a different SEH unwind purpose (e.g.
as part of setjmp/longjmp), but that case isn't handled properly at
the moment (the original unwind intent is lost and we end up with an
unhandled exception). This patch makes sure the foreign unwind terminates
as intended.

After executing a handler, _Unwind_Resume doesn't have access to
the target frame parameter of the original foreign unwind. We also
currently blindly set ExceptionCode to STATUS_GCC_THROW - we could
set that correctly by storing the original code in _GCC_specific_handler,
but we don't have access to the original target frame value.

This also matches what libgcc's SEH unwinding code does in this case.

Differential Revision: https://reviews.llvm.org/D89231
2020-10-12 23:28:22 +03:00
Louis Dionne 504bc07d1a [runtimes] Use int main(int, char**) consistently in tests
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.

One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
2020-10-08 14:28:13 -04:00
Daniel Kiss f34ae1b9de [AArch64] Add v8.5 Branch Target Identification support.
The .note.gnu.property must be in the assembly file to indicate the
support for BTI otherwise BTI will be disabled for the whole library.
__unw_getcontext and libunwind::Registers_arm64::jumpto() may be called
indirectly therefore they should start with a landing pad.

Reviewed By: tamas.petz, #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D77786
2020-09-29 15:51:01 +02:00
Ryan Prichard 881aba7071 [libunwind] Optimize dl_iterate_phdr's findUnwindSectionsByPhdr
Currently, findUnwindSectionsByPhdr is slightly micro-optimized for the
case where the first callback has the target address, and is otherwise
very inefficient -- it decodes .eh_frame_hdr even when no PT_LOAD
matches the PC. (If the FrameHeaderCache is enabled, then the
micro-optimization only helps the first time unwind info is looked up.)

Instead, it makes more sense to optimize for the case where the
callback *doesn't* find the target address, so search for a PT_LOAD
segment first, and only look for the unwind info section if a matching
PT_LOAD is found.

This change helps on an Android benchmark with 100 shared objects,
where the DSO at the end of the dl_iterate_phdr list throws 10000
exceptions. Assuming the frame cache is disabled, this change cuts
about 30-40% off the benchmark's runtime.

Reviewed By: compnerd, saugustine, #libunwind

Differential Revision: https://reviews.llvm.org/D87881
2020-09-23 15:40:39 -07:00
Ryan Prichard b16d6653c0 [libunwind] Combine dl_iterate_phdr codepaths for DWARF and EHABI
dl_iterate_phdr is used to search for unwind info provided by either
PT_GNU_EH_FRAME or PT_ARM_EXIDX. Most of the code between the two is
the same, so combine them, and factor out what's different into
checkForUnwindInfoSegment.

Details:
 - The FrameHeaderCache can now be enabled for ARM EHABI.
 - findUnwindSectionsByPhdr now finds the last PT_ARM_EXIDX rather than
   the first. There should only be one segment.
 - The dso_base and text_segment_length fields of UnwindInfoSections
   are now needed for dl_iterate_phdr when using EHABI, to hold the
   low and high PC values for a cache entry.

Reviewed By: compnerd, danielkiss, #libunwind, saugustine

Differential Revision: https://reviews.llvm.org/D87880
2020-09-23 15:40:39 -07:00
Dave Lee b36bdfe5ca [cmake] Centralize LLVM_ENABLE_WARNINGS option
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.

`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.

This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.

Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd

Differential Revision: https://reviews.llvm.org/D87243
2020-09-21 10:23:17 -07:00
Daniel Kiss 22b615a965 [libunwind] Support for leaf function unwinding.
Unwinding leaf function is useful in cases when the backtrace finds a
leaf function for example when it caused a signal.
This patch also add the support for the DW_CFA_undefined because it marks
the end of the frames.

Ryan Prichard provided code for the tests.

Reviewed By: #libunwind, mstorsjo

Differential Revision: https://reviews.llvm.org/D83573

Reland with limit the test to the x86_64-linux target.
2020-09-18 15:09:42 +02:00
Daniel Kiss 5831adb8c3 Revert "[libunwind] Support for leaf function unwinding."
This reverts commit 23bef7ee99.
2020-09-18 11:37:54 +02:00
Ryan Prichard fb1abe0063 [libunwind][DWARF] Fix end of .eh_frame calculation
* When .eh_frame is located using .eh_frame_hdr (PT_GNU_EH_FRAME), the
   start of .eh_frame is known, but not the size. In this case, the
   unwinder must rely on a terminator present at the end of .eh_frame.
   Set dwarf_section_length to UINTPTR_MAX to indicate this.

 * Add a new field, text_segment_length, that the FrameHeaderCache uses
   to track the size of the PT_LOAD segment indicated by dso_base.

 * Compute ehSectionEnd by adding sectionLength to ehSectionStart,
   never to fdeHint.

Fixes PR46829.

Differential Revision: https://reviews.llvm.org/D87750
2020-09-16 19:00:57 -07:00
Daniel Kiss 23bef7ee99 [libunwind] Support for leaf function unwinding.
Unwinding leaf function is useful in cases when the backtrace finds a
leaf function for example when it caused a signal.
This patch also add the support for the DW_CFA_undefined because it marks
the end of the frames.

Ryan Prichard provided code for the tests.

Reviewed By: #libunwind, mstorsjo

Differential Revision: https://reviews.llvm.org/D83573
2020-09-16 23:53:36 +02:00
Louis Dionne ec46cfefe8 [libcxx] Simplify back-deployment testing
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.

Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.

The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
   complicated, and it has been a source of bugs in the past. I have
   simplified it iteratively in the past, but the complexity is still
   there.
2. The deployment-target detection started failing in weird ways in
   recent Clangs, breaking our CI. Instead of band-aid patching the
   issue, I decided to remove the complexity altogether by using target
   triples even on Apple platforms.

A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
2020-09-10 08:17:26 -04:00
Ryan Prichard 09d492902f [libunwind] Bare-metal DWARF: set dso_base to 0
Previously, DwarfFDECache::findFDE used 0 as a special value meaning
"search the entire cache, including dynamically-registered FDEs".
Switch this special value to -1, which doesn't make sense as a DSO
base.

Fixes PR47335.

Reviewed By: compnerd, #libunwind

Differential Revision: https://reviews.llvm.org/D86748
2020-09-09 15:43:35 -07:00
Ryan Prichard 88bf133c99 [libunwind] Replace chain-of-ifdefs for dl_iterate_phdr
Define a _LIBUNWIND_USE_DL_ITERATE_PHDR macro in config.h when there is
no other unwind info lookup method. Also define a
_LIBUNWIND_USE_DL_UNWIND_FIND_EXIDX macro to factor out
(__BIONIC__ and _LIBUNWIND_ARM_EHABI).

Differential Revision: https://reviews.llvm.org/D86768
2020-09-08 15:49:35 -07:00
Ryan Prichard 673484b341 [libunwind] Minor SJLJ config cleanup. NFCI.
Simplify:

    defined(__ARM_DWARF_EH__) || !defined(__arm__)

to:

    !defined(_LIBUNWIND_ARM_EHABI)

A later patch benefits from the simplicity. This change will result in
the two DWARF macros being defined when __USING_SJLJ_EXCEPTIONS__ is
defined, but:

 * That's already the case with the __APPLE__ and _WIN32 clauses.
 * That's also already the case with other architectures.
 * With __USING_SJLJ_EXCEPTIONS__, most of the unwinder is #ifdef'ed
   away.

Generally, when __USING_SJLJ_EXCEPTIONS__ is defined, most of the
libunwind code is removed by the preprocessor. e.g. None of the hpp
files are included, and almost all of the .c and .cpp files are defined
away, except in Unwind-sjlj.c. Unwind_AppleExtras.cpp is an exception
because it includes two hpp files, which it doesn't use. Remove the
unneeded includes for consistency with the general rule.

Reviewed By: steven_wu

Differential Revision: https://reviews.llvm.org/D86767
2020-09-03 15:59:45 -07:00
Raul Tambre 45344cf7ac [CMake][compiler-rt][libunwind] Compile assembly files as ASM not C, unify workarounds
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Simply don't mark the file as C and CMake will recognize the rest.

This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple.
Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09.
Afterwards workarounds were added for MinGW and Apple:
* https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
* https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb

The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other.
The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287).

Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.

Example error:
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.

Differential Revision: https://reviews.llvm.org/D86308
2020-08-27 15:40:15 +03:00
Ryan Prichard 3071d5ffba [libunwind] Factor out getInfoFromFdeCie. NFCI.
Differential Revision: https://reviews.llvm.org/D86255
2020-08-26 18:22:06 -07:00
Ryan Prichard 7a457593ef [libunwind] Minor fixes in libunwind
* When _LIBUNWIND_SUPPORT_COMPACT_UNWIND is defined in config.h,
   define it to "1" like the other macros. These macros are still
   checked using "#if defined(...)", however.

 * Include libunwind.h in AddressSpace.hpp before using
   _LIBUNWIND_ARM_EHABI.

 * Rename ProcessFrameHeaderCache to TheFrameHeaderCache, because some
   configurations (e.g. Android / hermetic static libraries) can have
   one cache per shared object in the process. (When there are more
   copies, it's more important not to waste memory in the cache.)

 * Add 3 missing header files to LIBUNWIND_HEADERS.

Differential Revision: https://reviews.llvm.org/D86254
2020-08-26 18:22:03 -07:00
Martin Storsjö e524daa7e8 [libunwind] Convert x86, x86_64, arm64 register restore functions to C calling convention and name mangling
Currently, the assembly functions for restoring register state have
been direct implementations of the Registers_*::jumpto() method
(contrary to the functions for saving register state, which are
implementations of the extern C function __unw_getcontext). This has
included having the assembly function name match the C++ mangling of
that method name (and having the function match the C++ member
function calling convention). To simplify the interface of the assembly
implementations, make the functions have C calling conventions and
name mangling.

This fixes building the library in with a MSVC C++ ABI with clang-cl,
which uses a significantly different method name mangling scheme.
(The library might not be of much use as C++ exception unwinder in such
an environment, but the libunwind.h interface for stepwise unwinding
still is usable, as is the _Unwind_Backtrace function.)

Differential Revision: https://reviews.llvm.org/D86041
2020-08-26 14:32:32 +03:00
Mikael Holmen 1c39ffecd8 [libunwind] Fix warning when building without frameheader cache
Without the fix the compiler warns with

/data/repo/master/libunwind/src/AddressSpace.hpp:436:44: warning: unused parameter 'pinfo_size' [-Wunused-parameter]
                                    size_t pinfo_size, void *data) {
                                           ^
1 warning generated.
2020-08-25 12:58:39 +02:00
Ryan Prichard 9e32d7b6e7 [libunwind] Remove static_assert / __has_feature macros
The static_assert macro broke on GCC when a scope had two asserts and a
condition that depended on a template parameter. Remove the macro and
rely on the compiler's C++11 static_assert feature.

The __has_feature macro was only used here to determine whether to
define the static_assert macro.

Reviewed By: mstorsjo, #libunwind

Differential Revision: https://reviews.llvm.org/D86411
2020-08-24 14:07:20 -07:00
Ryan Prichard 3c1b2e338d [libunwind] Make findUnwindSectionsByPhdr static
Currently, this function is present in the dynsym table of
libunwind.so (on ELF targets). Make the function static instead.

In the previous release (LLVM 10.x), this function was instead a lambda
function inside LocalAddressSpace::findUnwindSections, and because
LocalAddressSpace was marked with _LIBUNWIND_HIDDEN, the lambda
function was also a hidden symbol.

Differential Revision: https://reviews.llvm.org/D86372
2020-08-22 17:12:52 -07:00
Martin Storsjö 542db87f1a [libunwind] Ensure enough alignment for unw_cursor_t for SEH build configurations
When built in SEH mode, UnwindCursor contains a CONTEXT struct,
which is aligned to 16 bytes in most configurations, causing the
whole UnwindCursor object to have 16 byte alignment.

This fixes backtraces using _Unwind_Backtrace on x86_64 mingw,
where an unw_cursor_t allocated on the stack was misaligned before.

This is an ABI break for this struct for this configuration, but very
few callers call libunwind directly (and even fewer directly allocate
an unw_cursor_t anyway).

Differential Revision: https://reviews.llvm.org/D86102
2020-08-22 22:48:57 +03:00
Sterling Augustine a20f5fe708 Default to disabling the libunwind frameheader cache.
Although it works fine with glibc, as currently implemented the
frameheader cache is incompatible with certain platforms with
slightly different locking semantics inside dl_iterate_phdr.

Therefore only enable it when it is turned on explicitly with
a configure-time option.

Differential Revision: https://reviews.llvm.org/D86163
2020-08-18 14:37:36 -07:00
Steven Wu 4cd09374cd [libunwind] Remove compatibility support for macOS 10.6
Remove `_dyld_find_unwind_sections` implementation for macOS that is
10.6 or previous. 10.6 is no longer supported for TOT libunwind after
removing its libkeymgr dependency.

Reviewed By: mstorsjo, pete, #libunwind

Differential Revision: https://reviews.llvm.org/D86104
2020-08-17 14:09:03 -07:00
Louis Dionne 9b211a5076 [libunwind] Fix incorrect check for out-of-boundedness
If the personalityIndex (which is 0-based) is equal to the length of
the personality array, we should error out.

rdar://18013273
2020-08-11 15:37:57 -04:00
Louis Dionne e8dac8b3db [libunwind][NFC] Fix typo in comment 2020-08-11 15:24:52 -04:00
Daniel Kiss 9c3f6fb688 [libunwind] Make the test depend on the libunwind explicitly.
Before this patch the `ninja check-unwind` won't rebuild the unwind library.

Reviewed By: jroelofs

Differential Revision: https://reviews.llvm.org/D85004
2020-08-03 09:46:23 +02:00
kristina 46591b9536 [libunwind] Add -Wno-suggest-override to CMakeLists.txt.
Set -Wno-suggest-override where such warning is provided
by the compiler when building libunwind, alongside libcxx
and libcxxabi, using recent Clang. This extends behavior
introduced in 77e0e9e17d
to libunwind, avoiding a large amount of warnings during
builds. See D84126 for the original patch.
2020-07-31 19:04:13 +01:00
Hafiz Abid Qadeer 380fee34d2 [libunwind] Provide a way to set '_LIBUNWIND_IS_BAREMETAL' through cmake.
Libunwind uses _LIBUNWIND_IS_BAREMETAL in a lot of places but there is no cmake variable to set it. This patch adds such a variable. It is quite like what LIBCXXABI_BAREMETAL does in libcxxabi.

Reviewed By: compnerd, #libunwind

Differential Revision: https://reviews.llvm.org/D84759
2020-07-29 11:48:28 +01:00
Louis Dionne 145acacaea [libunwind] Remove old keymgr related logic
keymgr used to be used on MacOSX <= 10.6, however we don't build libunwind
from scratch for such old systems anymore. Hence, this code isn't useful
anymore.

Differential Revision: https://reviews.llvm.org/D84677
2020-07-27 16:12:59 -04:00
Louis Dionne afa1afd410 [CMake] Bump CMake minimum version to 3.13.4
This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.

This is part of the effort discussed on llvm-dev here:

  http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

Differential Revision: https://reviews.llvm.org/D78648
2020-07-22 14:25:07 -04:00
Louis Dionne ff0d4367bf [runtimes] Move the enable_rtti Lit parameter to the DSL 2020-07-16 12:56:00 -04:00
Louis Dionne 0f03626fbf [runtimes][NFC] Remove unused or unnecessary CMake variables 2020-07-16 10:47:08 -04:00
Ryan Prichard fd802cc4de [libunwind] Fix getSLEB128 on large values
Previously, for large-enough values, getSLEB128 would attempt to shift
a signed int in the range [0..0x7f] by 28, 35, 42... bits, which is
undefined behavior and likely to fail.

Avoid shifting (-1ULL) by 70 for large values. e.g. For INT64_MAX, the
last two bytes will be:
 - 0x7f [bit==56]
 - 0x00 [bit==63]

Differential Revision: https://reviews.llvm.org/D83742
2020-07-15 19:12:56 -07:00
Ryan Prichard 52d0a78b83 [libunwind] Fix CIE v1 return address parsing
- For CIE version 1 (e.g. in DWARF 2.0.0), the return_address_register
   field is a ubyte [0..255].

 - For CIE version 3 (e.g. in DWARF 3), the field is instead a ULEB128
   constant.

Previously, libunwind accepted a CIE version of 1 or 3, but always
parsed the field as ULEB128.

Clang always outputs CIE version 1 into .eh_frame. (It can output CIE
version 3 or 4, but only into .debug_frame.)

Differential Revision: https://reviews.llvm.org/D83741
2020-07-15 19:12:55 -07:00
Hans Wennborg 7ab7b979d2 Bump the trunk major version to 12
and clear the release notes.
2020-07-15 12:05:05 +02:00
Louis Dionne 70f6389257 [runtimes] Rename newformat to just format, now that the old format has been removed 2020-06-30 10:10:30 -04:00
Louis Dionne 5d83880885 [runtimes] Remove the ability to select the old libc++ testing format
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.

[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
2020-06-29 14:07:41 -04:00
Louis Dionne c55051eea5 [libunwind] Allow specifying custom Lit config files
This is the libunwind counterpart of 0c66af970c.
2020-06-25 12:15:15 -04:00
Saleem Abdulrasool 2d865ccbd8 unwind: EHABISectionIterator `operator!=`, constify `operator-`
Add missing `operator!=` and make `operator-` const for
`EHABISectionIterator`.  This repairs the build of libunwind when
building with GCC.

Patch by Chad Duffin!

Reviewed By: compnerd, libunwind
Differential Revision: https://reviews.llvm.org/D81597
2020-06-18 08:54:34 -07:00
Amanieu d'Antras 0c1a135ada [libunwind][RISCV] Track PC separately from RA
Summary:
This allows unwinding to work across signal handler frames where the IP of the previous frame is not the same as the current value of the RA register. This is particularly useful for acquiring backtraces from signal handlers.

I kept the size of the context structure the same to avoid ABI breakage; the PC is stored in the previously unused slot for register 0.

Reviewers: #libunwind, mhorne, lenary, luismarques, arichardson, compnerd

Reviewed By: #libunwind, mhorne, lenary, compnerd

Subscribers: kamleshbhalui, jrtc27, bsdjhb, arichardson, compnerd, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, psnobl, benna, Jim, s.egerton, sameer.abuasal, evandro, llvm-commits, libcxx-commits

Tags: #libunwind, #llvm

Differential Revision: https://reviews.llvm.org/D78931
2020-06-13 08:15:40 +01:00
Louis Dionne 96e6cbbf94 [libc++] Allow specifying arbitrary custom executors with the new format
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.

This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.

Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
2020-06-11 16:24:29 -04:00
Louis Dionne 168681abce [libc++abi][libunwind] Don't override libc++'s handling of exception features
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.

This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
2020-06-09 16:03:22 -04:00
Louis Dionne 0e04342ae0 [NFCI] Clean up exceptions related CMake and Lit options in libc++abi and libunwind
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.

Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
2020-06-09 15:34:29 -04:00
Saleem Abdulrasool 68c50708d1 unwind: use a more portable endianness check in EHABI
The ARM specific code was trying to determine endianness using the
`__LITTLE_ENDIAN__` macro which is not guaranteed to be defined.
When not defined, it makes libunwind to build the big-endian code even
when the compiler builds for a little-endian target.

This change allows building libunwind with the `musl-gcc` toolchain
which does not define `__LITTLE_ENDIAN__`.  Use `__BYTE_ORDER__`
instead.

Patch by Idan Freiberg!
2020-05-29 08:28:37 -07:00
Saleem Abdulrasool b31cb3aa5e unwind: fix unwind build without heap
Add a missing guard for `_LIBUNWIND_NO_HEAP` around code dealing with the
`.cfi_remember_state` and `.cfi_restore_state` instructions.

Patch by Amanieu d'Antras!
2020-05-15 14:45:22 -07:00
Shoaib Meenai cc259638cb [libcxx][libcxxabi][libunwind] Use libgcc on Android
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.

Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines

Differential Revision: https://reviews.llvm.org/D78787
2020-04-30 15:42:32 -07:00
Louis Dionne 8c61114c53 [libc++/abi/unwind] Rename Lit features for no exceptions to 'no-exceptions'
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.

Differential Revision: https://reviews.llvm.org/D78370
2020-04-22 08:25:27 -04:00
Louis Dionne 5f7a030162 [libunwind] Enable the new libc++ testing format by default
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ and libc++abi tests. This commit
changes the libunwind tests to use the new format by default too. If
unexpected failures are discovered, it should be fine to revert this
commit until they are addressed.

Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.

Differential Revision: https://reviews.llvm.org/D77733
2020-04-13 18:17:18 -04:00
Brian Cain 9107594f37 [libunwind] add hexagon support 2020-04-10 04:24:10 -05:00
Fangrui Song f3d460ce58 [libunwind] Clean up __arm64__
`__aarch64__` is defined for the target (since the beginning of arm64 support: clang 3.5).
`__arm64__` is only defined for the Darwin OS on AArch64.

`defined(__aarch64__) || defined(__arm64__)` can be simplied as `defined(__aarch64__)`

Darwin AArch64 uses %% as the assembly separator (see AArch64MCAsmInfo.cpp).
Make the intention explicit in src/assembly.h

With this change, the libunwind code base has no reference of `__arm64__`/`__arm64`.

Reviewed By: #libunwind, ldionne, mstorsjo

Differential Revision: https://reviews.llvm.org/D77829
2020-04-09 15:46:48 -07:00
Louis Dionne 6f1d558db4 [libunwind] Fix incorrect lit substitutions in tests
The LIT substitutions used in libunwind are the same as those from
libc++, and we forgot to update the libunwind tests after the libc++
substitutions started being delimited by braces.
2020-04-08 10:50:09 -04:00
Jorge Gorbe Moya 82576d6fec [libunwind] Fix UB in EHHeaderParser::findFDE
When the EHHeaderInfo object filled by decodeEHHdr has fde_count == 0,
findFDE does the following:

- sets low = 0 and len = hdrInfo.fde_count as a preparation to start a
  binary search
- because len is 0, the binary search loop is skipped
- the code still tries to find a table entry at
  hdrInfo.table + low * tableEntrySize, and decode it.

This is wrong when fde_count is 0, and trying to decode a table entry
that isn't there will lead to reading garbage offsets and can cause
segfaults.

Differential Revision: https://reviews.llvm.org/D77679
2020-04-07 14:44:42 -07:00
Sergej Jaskiewicz 649f042802 [libunwind] Support the new libc++ test format
Reviewers: ldionne, #libunwind, mstorsjo

Reviewed By: ldionne, #libunwind, mstorsjo

Subscribers: mstorsjo, dexonsmith, llvm-commits, libcxx-commits

Tags: #llvm, #libunwind

Differential Revision: https://reviews.llvm.org/D77501
2020-04-06 23:26:59 +03:00
Sterling Augustine 71fbd6e406 Exit unwinding early when at the top of the stack and additional info won't be found.
Summary:
This patch follows libgcc's lead: When the return-address register is
zero, there won't be additional stack frames to examine, or gather
information about. Exit before spending time looking for something
known not to be found.

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77099
2020-04-02 10:52:25 -07:00
Sylvestre Ledru 72fd1033ea Doc: Links should use https 2020-03-22 22:49:33 +01:00
Mikael Holmen abc238a3c7 [libunwind] Silence warnings when __mips_hard_float is not defined
The warnings started showing up for me with c53c2058ff which builds
Registers.hpp.
2020-03-13 09:19:56 +01:00
Sterling Augustine 3758b858ef Only run frameheader_cache_test.pass.cpp on x86_64.
Although there is nothing architecturally specific, the
ifdef chains are too complicated otherwise.
2020-03-12 18:14:22 -07:00
Sterling Augustine 3eef58991b Add a catch-all else case so any unanticipated configs pass this test. 2020-03-12 11:55:10 -07:00
Sterling Augustine c53c2058ff Cache uwnind frame headers as they are found.
Summary:
This improves unwind performance quite substantially, and follows
a somewhat similar approach used in libgcc_s as described in the
thread here:

https://gcc.gnu.org/ml/gcc/2005-02/msg00625.html

On certain extremely exception heavy internal tests, the time
drops from about 80 minutes to about five minutes.

Subscribers: libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75954
2020-03-12 10:53:33 -07:00
Sterling Augustine 8ffdabdb61 Lazily save initialState of registers during unwind.
Summary:
Copying all of the saved register state on every entry to
parseInstruction is a severe performance contraint, especially
because most of this saved state is never used. On x86 linux
this is about 560 bytes, and will be more on other platforms.

When performance testing libunwind, this memcpy appears at the
top of nearly all our tests.

By only saving this state as needed, we see increasing in performance
of around 2.5% for the ctak test here.

https://github.com/clasp-developers/ctak

Certain internal extremely exception-heavy tasks run in about 2/3
the time.

Note that by stashing the new boolean inside what had been padding in
the original structure, this uses no additional memory.

Subscribers: fedor.sergeev, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75692
2020-03-11 10:13:33 -07:00
Leonard Chan 1c70dec18c [libunwind] Remove __FILE__ and __LINE__ from error reporting
We were seeing non-deterministic binary size differences depending on which
toolchain was used to build fuchsia. This is because libunwind embeded the
FILE path into a logging macro, even for release builds, which makes the code
dependent on the build directory.

This removes the file and line number from the error message. This is
consistent with how other runtimes report error, e.g.
https://github.com/llvm/llvm-project/blob/master/libcxxabi/src/abort_message.cpp#L30.

Differential Revision: https://reviews.llvm.org/D75890
2020-03-10 18:58:41 -07:00
Sterling Augustine d67cf7a0a9 Rework findUnwindSectionsByPhdr to be more optimal.
Summary:
- Executable segment is usually segment 3. Look there for the address first.
- GNU_EH_FRAME_HEADER segment is usually near the end. Iterate from the end.
- Exit early if both phdrs have been found.

This is the last cl before a patch to cache the information this function
finds.

Subscribers: libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75781
2020-03-10 10:35:15 -07:00
Sterling Augustine eb755df5c2 Split findUnwindSectionsByPhdr into target-specific functions.
Summary:
This further cleans up the control flow and makes it easier to
optimize and replace portions in a subsequent patch.

This should be NFC, but given the amount of #ifdeffing here,
it may not be. So will watch the buildbots closely.

Also, as this is purely moving existing code around, I plan to
ignore the lint errors.

Reviewers: compnerd, miyuki, mstorsjo

Subscribers: libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75705
2020-03-06 13:28:09 -08:00
Sterling Augustine 470f995a51 Promote nameless lambda used by dl_iterate_phdr to named function.
Summary:
This cleans up control flow inside findUnwindSections, and will make
it easier to replace this code in a following patch. Also, expose the
data structure to allow use by a future replacment function.

Reviewers: mstorsjo, miyuki

Subscribers: krytarowski, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75637
2020-03-05 08:55:22 -08:00
Mikhail Maltsev 00c5793ede Revert "Promote nameless lambda used by dl_iterate_phdr to named function to clean up control flow inside findUnwindSections. Also, expose the data structure"
This reverts commit d93371238e.

The commit broke the build in several configurations (including
Windows and bare-metal). For details see comments in
https://reviews.llvm.org/D75480
2020-03-04 14:54:24 +00:00
Sterling Augustine d93371238e Promote nameless lambda used by dl_iterate_phdr to named function to clean up control flow inside findUnwindSections. Also, expose the data structure
to allow use by a future replacment function.

Summary: [Refactor] Promote nameless lambda to fully named function, allowing easy replacement in following patch.

Subscribers: krytarowski, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75480
2020-03-03 09:13:01 -08:00
Shoaib Meenai e34ddc09f4 [arcconfig] Delete subproject arcconfigs
From https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/:

> An .arcconfig file is a JSON file which you check into your project's root.

I've done some experimentation, and it looks like the subproject
.arcconfigs just get ignored, as the documentation says. Given that
we're fully on the monorepo now, it's safe to remove them.

Differential Revision: https://reviews.llvm.org/D74996
2020-02-24 16:20:36 -08:00
Michael Spencer d4ded05ba8 [libunwind][CMake] Treat S files as C to work around CMake bug.
The OSX_ARCHITECTURES property is supposed to add the -arch flag when
targeting Apple platforms. However, due to a bug in CMake
(https://github.com/Kitware/CMake/blob/master/Source/cmLocalGenerator.cxx#L1780),
this does not apply to assembly files. This results in a linker error
when trying to build libunwind for i386 on MacOS.

rdar://59642189
2020-02-20 15:26:09 -08:00
Jorge Gorbe Moya 1ae8d81147 [libunwind] Fix memory leak in handling of DW_CFA_remember_state and DW_CFA_restore_state
parseInstructions() doesn't always process the whole set of DWARF
instructions for a frame. It will stop once the target PC is reached, or
if malformed instructions are found. So, for example, if we have an
instruction sequence like this:

```
<start>
...
DW_CFA_remember_state
...
DW_CFA_advance_loc past the location we're unwinding at (pcoffset in parseInstructions() main loop)
...
DW_CFA_restore_state
<end>
```

... the saved state will never be freed, even though the
DW_CFA_remember_state opcode has a matching DW_CFA_restore_state later
in the sequence.

This change adds code to free whatever is left on rememberStack after
parsing the CIE and the FDE instructions.

Differential Revision: https://reviews.llvm.org/D66904
2020-02-18 11:57:18 -08:00
Saleem Abdulrasool 14798b4465 unwind: rename `__personality_routine` to `_Unwind_Personality_Fn`
This patch renames `__personality_routine` to `_Unwind_Personality_Fn`
in `unwind.h`. Both `unwind.h` from clang and GCC headers use this name
instead of `__personality_routine`. With this patch one is also able to
build libc++abi with libunwind support on Windows.

Patch by Markus Böck!
2020-02-10 08:52:31 -08:00
Nico Weber 221c5af4e4 Fix a -Wbitwise-conditional-parentheses warning in _LIBUNWIND_ARM_EHABI 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
2020-02-03 14:17:50 -05:00
Martin Storsjö b780df052d [libunwind] Treat assembly files as C on mingw
When targeting mingw, current CMake (3.16) fails to get the right
flags for assembly source files for windows gnu/clang targets
(see https://gitlab.kitware.com/cmake/cmake/merge_requests/4287
for a fix), causing builds to fail due to `-fPIC` being unsupported
in clang for mingw targets

In the meantime, restore the behaviour from before c48974ffd7
selectively on mingw targets, treating the assembly files as C.

Differential Revision: https://reviews.llvm.org/D73436
2020-01-27 09:04:58 +02:00
Martin Storsjö 0e0c65264a [libunwind] Fix building standalone after c48974ffd7
After this change, we need to explicitly list the languages the
project uses, otherwise the assembly source files won't get built
at all.

Previously (before that commit), the assembly source files were
simply treated as C.

The toplevel llvm CMakeLists.txt adds these three languages, so
when building libunwind integrated as part of that, it works fine.
2020-01-26 22:12:40 +02:00
James Nagurne c48974ffd7 [libunwind] Set LIBUNWIND_ASM_SOURCES to the ASM source language from C
I believe this is an oversight from the import of libunwind into its own
library from libc++abi.

In libc++abi, these files had the .s suffix, which indicates that the file
is a preprocessed assembly source file. This caused problems because the
files rely upon preprocessors to guard target-specific blocks.

To fix this, the CMakeLists file marked these files as C so that the
preprocessor would be run over them, but then the compiler would correctly
identify the files as assembly and compile them as such.

When imported to libunwind, these files were (correctly) renamed with .S
suffixes, which are non-preprocessed assembly. Thus, we no longer need the
C language property.

The benefit here is that the files can now benefit from CMAKE_ASM_FLAGS
rather than CMAKE_C_FLAGS.

Patch By: JamesNagurne

Differential Revision: https://reviews.llvm.org/D72952
2020-01-24 19:16:47 -08:00
Hans Wennborg 5852475e2c Bump the trunk major version to 11
and clear the release notes.
2020-01-15 13:38:01 +01:00
Steven Wu 9366397f05 [libunwind] Fix evaluating DWARF operation DW_OP_pick
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
2019-12-18 12:22:21 -08:00
Petr Hosek 547659ae56 [unwind] Don't link libpthread and libdl on Fuchsia
This is a follow up to D71135.
2019-12-17 17:21:43 -08:00
Sam Elliott ce3d1c6d61 [libunwind][RISCV] Add 64-bit RISC-V support
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
2019-12-16 16:36:56 +00:00
Sergej Jaskiewicz 57fc8ecdba Reland "Enable `-funwind-tables` flag when building libunwind"
Summary:
Relands https://reviews.llvm.org/D70815.

The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to
`STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively
disabled the linking step in CMake checks.

This broke some builds (see 938c70b86c).

Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to
STATIC_LIBRARY only when checking for presence of the `-funwind-tables`
flag, and then set it back to the original value so it doesn't affect
other checks.

Reviewers: mstorsjo, jfb

Subscribers: mgorny, christof, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D71117
2019-12-11 04:27:04 +03:00
Martin Storsjö 938c70b86c Revert "Enable `-funwind-tables` flag when building libunwind"
This reverts commit b3fdf33ba6.

This change broke building libunwind for Windows/MinGW, and broke
on aspect of the CMake tests in libunwind in general.

After set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), CMake
skips the linking step in tests, but cmake/config-ix.cmake also
does a few checks for functions in libraries (looking for whether
-lc provides fopen and whether -ldl provides dladdr).

As CMake only tests building a static library, these tests
incorrectly succeed and CMake concludes "Looking for fopen in c -
found" and "Looking for dladdr in dl - found", while building
then fails at the end with errors about unable to find -lc and -ldl.
2019-12-04 09:29:15 +02:00
Sergej Jaskiewicz b3fdf33ba6 Enable `-funwind-tables` flag when building libunwind
Summary:
Or, rather, don't accidentally forget to pass it.

This is aimed to solve the problem discussed in [this thread](http://lists.llvm.org/pipermail/llvm-dev/2019-November/136890.html), and to fix [a year-old bug](https://bugs.llvm.org/show_bug.cgi?id=38468).

TL;DR: when building libunwind for ARM Linux, we **need** libunwind to be built with the `-funwind-tables` flag, because, well ARM EHABI needs unwind info produced by this flag. Without the flag all the procedures in libunwind are marked `.cantunwind`, which causes all sorts of bad things. From `_Unwind_Backtrace` not working, to C++ exceptions not being caught (which is the aforementioned bug is about).

Previously, this flag was not added because the CMake check `add_compile_flags_if_supported(-funwind-tables)` produced a false negative. Why? With this flag, the compiler generates calls to the `__aeabi_unwind_cpp_pr0` symbol, which is defined in libunwind itself and obviously is not available at configure time, before libunwind is built. This led to failure at link time during the CMake check. We handle this by disabling the linker for CMake checks in linbunwind.

Also, this patch introduces a lit feature `libunwind-arm-ehabi`, which is used to mark the `signal_frame.pass.cpp` test as unsupported (as was advised by @miyuki in D70397).

Reviewers: peter.smith, phosek, EricWF, compnerd, jroelofs, saugustine, miyuki, jfb

Subscribers: mgorny, kristof.beyls, christof, libcxx-commits, miyuki

Tags: #libc

Differential Revision: https://reviews.llvm.org/D70815
2019-12-04 00:52:19 +03:00
Michał Górny 35bc5276ca [libunwind] Emit dependent libraries only when detected by CMake
996e62eef7 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
2019-12-01 17:17:51 +01:00
Mikhail Maltsev 4fb8ecdef4 [libunwind] Adjust the signal_frame test for Arm
Summary:
This patch adjusts the signal_frame.pass.cpp to pass on Arm targets:
* When Arm EHABI is used the unwinder does not use DWARF, hence the
  DWARF-specific check unw_is_signal_frame() must be disabled.
* Certain C libraries don't include EH tables, so the unwinder must
  not try to step out of main(). The patch moves the test code out of
  main() into a separate function to avoid this.

Reviewers: saugustine, ostannard, phosek, jfb, mclow.lists

Reviewed By: saugustine

Subscribers: dexonsmith, aprantl, kristof.beyls, christof, libcxx-commits, pbarrio, labrinea

Tags: #libc

Differential Revision: https://reviews.llvm.org/D70397
2019-11-19 09:58:46 +00:00
Nick Desaulniers 49fb4a96e0 change LLVM_VERSION_SUFFIX default from svn to git
Summary:
Sayonara SVN!

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewers: tstellar, jyknight, lebedev.ri, smeenai, mgorny, hans, mclow.lists

Reviewed By: mgorny, hans

Subscribers: christof, libcxx-commits, llvm-commits, srhines

Tags: #libc, #llvm

Differential Revision: https://reviews.llvm.org/D70019
2019-11-11 09:10:20 -08:00
Sterling Augustine d3c744313c Correctly update isSignalFrame when unwinding the stack via dwarf.
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
2019-11-07 14:48:35 -08:00
Saleem Abdulrasool e74e61ff29 unwind: restore the LINKER_LANGUAGE
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.
2019-11-06 15:42:09 -08:00
Saleem Abdulrasool aa582e3648 unwind: reflow some of the build rules (NFC)
Reflow the CMake properties to take less vertical space.  This just
makes it easier to read.  NFC.
2019-11-06 15:42:09 -08:00
Saleem Abdulrasool cbc872a63f unwind: disable RTTI during the build of libunwind
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`.
2019-11-06 10:51:42 -08:00
Saleem Abdulrasool 049f94af48 Revert "build: explicitly set the linker language for unwind"
This reverts commit 6db7a5cd7c.
This adversely impacted the NetBSD libc++ bot for some reason, reverting
while investigating.
2019-11-06 08:34:13 -08:00
Saleem Abdulrasool 6db7a5cd7c build: explicitly set the linker language for unwind
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++`.
2019-11-04 16:55:31 -08:00
Martin Storsjö 08c7ff99e1 [libunwind] [Windows] Add a log message if EnumProcessModules fails
Differential Revision: https://reviews.llvm.org/D69504
2019-10-31 09:34:39 +02:00
Ryan Prichard 788acc6ff8 [libunwind][Android] Fix findUnwindSections for ARM EHABI Bionic
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
2019-10-18 19:59:22 +00:00
Ryan Prichard 8200dbbcae [libunwind][Android] Improve workaround for PIE zero-dlpi_addr bug
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
2019-10-16 02:38:47 +00:00
Petr Hosek e3250b0c40 [libunwind] Fix issues introduced in r374606
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
2019-10-12 01:50:57 +00:00
Petr Hosek 20da3bdb96 [libunwind] Refactor CMake flag checks to match libc++ and libc++abi
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
2019-10-11 22:22:29 +00:00
John Brawn b44204c77e [libunwind] Adjust libunwind_01.pass.cpp test for ARM EHABI
ARM EHABI unwinding tables only store the start address of each function, so the
last function is assumed to cover the entire address space after it. The test
picks an address on the stack assuming that it's in no function, but because of
the above it's actually resolved to the last function. Fix this by using address
0 instead.

Differential Revision: https://reviews.llvm.org/D68387

llvm-svn: 373628
2019-10-03 17:01:04 +00:00
Saleem Abdulrasool 0ae02fd71a Unwind: avoid warning about unused typedef
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
2019-09-20 20:46:33 +00:00
Saleem Abdulrasool ae685e7aab Unwind: prevent unw_get_proc_info from returning stale data
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
2019-09-20 15:53:42 +00:00
Saleem Abdulrasool 8f16cc46f7 unwind: remove a could of extraneous `else` (NFC)
Simplify `if return else return` by removing the unnecessary `else`.

llvm-svn: 372233
2019-09-18 16:15:56 +00:00
Yi Kong d8bdb9225c [runtimes] Don't depend on libpthread on Android
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
2019-07-22 20:41:03 +00:00
Mikhail Maltsev b64b900962 [libunwind][ARM] Fix types in _Unwind_VRS_Get.
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
2019-07-22 16:43:03 +00:00
Mikhail Maltsev f41e627157 [libunwind][ARM] Fix loading FP registers on big-endian targets
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
2019-07-19 15:20:32 +00:00
Hans Wennborg 8f5b44aead Bump the trunk version to 10.0.0svn
and clear the release notes.

llvm-svn: 366427
2019-07-18 11:51:05 +00:00
Mikhail Maltsev a448ed99df [libunwind] Fix Unwind-EHABI.cpp:getByte on big-endian targets
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
2019-07-09 15:29:06 +00:00
Mikhail Maltsev d5323f6a70 [libunwind][AArch64] Fix libunwind::Registers_arm64::jumpto
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
2019-06-17 11:00:21 +00:00
J. Ryan Stinnett d45eaf9405 [Docs] Modernize references to macOS
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
2019-05-30 16:46:22 +00:00
Petr Hosek 433a191683 [CMake] Use find_package(LLVM) instead of LLVMConfig
This addresses an issues introduced in r362047.

Differential Revision: https://reviews.llvm.org/D62640

llvm-svn: 362065
2019-05-30 07:34:39 +00:00
Petr Hosek f1ddf431b5 [runtimes] Use -Wunknown-pragmas for the pragma check
This is a follow up to r362055, we need -Wunknown-pragmas otherwise
the check is going to succeed it the pragma isn't supported.

llvm-svn: 362057
2019-05-30 05:38:06 +00:00
Petr Hosek 789b7f0828 [runtimes] Check if pragma comment(lib, ...) is supported first
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
2019-05-30 04:40:21 +00:00
Petr Hosek 996e62eef7 [runtimes] Support ELF dependent libraries feature
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
2019-05-30 01:34:41 +00:00
Michal Gorny e04b002cf8 [libunwind] [test] Fix inferring source paths
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
2019-05-29 07:20:30 +00:00
Petr Hosek 81f433b48c [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and 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
2019-05-22 21:08:33 +00:00
Martin Storsjo 905af40cc6 [PPC] Fix 32-bit build of libunwind
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
2019-05-16 06:49:20 +00:00
Martin Storsjo 44266b9e11 [PPC64][libunwind] Fix r2 not properly restored
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
2019-05-16 06:49:13 +00:00
Sterling Augustine 7981a28d9d Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force
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
2019-05-13 18:45:03 +00:00
Petr Hosek f0652f03b6 [gn] Support for building libunwind
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
2019-05-02 17:29:37 +00:00
Louis Dionne 4256cf1b04 [NFC] Fix typo in debug log
llvm-svn: 358896
2019-04-22 15:40:50 +00:00
Martin Storsjo a88a020612 Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)
Patch by Jérémie Faucher-Goulet!

Differential Revision: https://reviews.llvm.org/D60417

llvm-svn: 358642
2019-04-18 06:35:42 +00:00
Nicolas Lesser b95559c964 [NFC] Move the export attribute after extern "C".
Not all compilers support attributes before `extern "C"`. gcc is the main one
that doesn't support it.

llvm-svn: 358301
2019-04-12 18:34:19 +00:00
Louis Dionne 2b0da3d63e [NFC] Correct outdated links to the Itanium C++ ABI documentation
Those are now hosted on GitHub.

rdar://problem/36557462

llvm-svn: 358191
2019-04-11 16:37:07 +00:00
Petr Hosek 3aeb6585d3 [libunwind] Fix the typo in unw_save_vfp_as_X alias
This was accidentaly introduced in r357640.

llvm-svn: 358164
2019-04-11 13:08:44 +00:00
Martin Storsjo 351ac8b1cc Move the alias definition of unw_getcontext to within !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
2019-04-04 17:50:14 +00:00
Petr Hosek ee676e2f6f [libunwind] Export the weak alias in Mach-O
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
2019-04-04 03:36:35 +00:00
Petr Hosek e369a989fc [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

llvm-svn: 357640
2019-04-03 21:50:03 +00:00
Petr Hosek 1de15f6f33 [libunwind] Do not share an object library to create the static/shared libraries
This change is similar to r356150, with the same motivation.

llvm-svn: 357606
2019-04-03 16:59:33 +00:00
Matthew Voss 1262e52e16 Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"
This broke the windows bots.

This reverts commit 28302c66d2.

llvm-svn: 355725
2019-03-08 20:33:55 +00:00
Petr Hosek 28302c66d2 [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
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
2019-03-08 05:35:22 +00:00
Petr Hosek dc1b8e9f44 [CMake][libunwind] Define add_target_flags which is missing
It's use was introduced in r353084 but its definition is missing.

Differential Revision: https://reviews.llvm.org/D58745

llvm-svn: 355142
2019-02-28 21:38:59 +00:00
Petr Hosek d2f3882def [CMake] Don't cache LLVM_MAIN_SRC_DIR
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
2019-02-13 07:09:26 +00:00
Petr Hosek 97bc08ae02 [CMake] Support compiler-rt builtins library in tests
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
2019-02-05 19:50:47 +00:00
Petr Hosek 3ad50fed48 [CMake] Update lit test configuration
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
2019-02-05 04:44:03 +00:00
Petr Hosek 6fd4e7fe02 [CMake] Support CMake variables for setting target, sysroot and toolchain
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
2019-02-04 20:02:26 +00:00
Martin Storsjo 6ccad0a7d0 Provide a placement new definition for the SEH version of UnwindCursor
This fixes compilation after SVN r352966 in SEH mode.

llvm-svn: 353010
2019-02-03 22:16:53 +00:00
Petr Hosek 5745e90800 [libunwind] Provide placement new definition
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
2019-02-02 21:15:49 +00:00
Petr Hosek 368c02e3ec [libunwind] Remove the remote unwinding support
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
2019-02-02 20:54:03 +00:00
Petr Hosek 8e78915446 [CMake] Use correct visibility for linked libraries in CMake
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
2019-01-30 23:18:05 +00:00
Petr Hosek c0b3d36990 Revert "[CMake] Use correct visibility for linked libraries in CMake"
This reverts commit r352654: this broke libcxx and sanitizer bots.

llvm-svn: 352658
2019-01-30 19:51:18 +00:00
Petr Hosek b9128d8def [CMake] Use correct visibility for linked libraries in CMake
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
2019-01-30 19:27:26 +00:00
Petr Hosek 3cfc55cf9c [libunwind] Support building hermetic static library
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
2019-01-29 23:01:08 +00:00
Petr Hosek 7fac51724f Drop the dependency on <algorithm>, add placement new inline
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
2019-01-29 22:26:18 +00:00
James Y Knight 5d71fc5d7b Adjust documentation for git migration.
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
2019-01-29 16:37:27 +00:00
Martin Storsjo d27bec4854 Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__
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
2019-01-29 09:00:32 +00:00
Petr Hosek 4ecdb70424 Revert "[libunwind] Drop the dependency on <algorithm>, add placement new inline"
This reverts commit r352384: this broke on ARM as UnwindCursor.hpp
still has some C++ library dependencies.

llvm-svn: 352427
2019-01-28 20:55:12 +00:00
Petr Hosek 12f4b86808 Revert "[CMake] Use __libc_start_main rather than fopen when checking for C 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
2019-01-28 19:26:41 +00:00
Petr Hosek 91a606e6c4 [libunwind] Drop the dependency on <algorithm>, add placement new inline
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
2019-01-28 16:44:56 +00:00
Petr Hosek b667153cf6 [CMake] Use __libc_start_main rather than fopen when checking for C library
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
2019-01-28 04:12:54 +00:00
Petr Hosek 90bcfaa2a0 [libunwind] Use placement new to avoid dependency C++ library
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
2019-01-25 21:39:46 +00:00
Petr Hosek 8c84e00c71 [libunwind] Don't abort if encoutering invalid .eh_frame_hdr
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
2019-01-24 03:04:42 +00:00
Martin Storsjo ea5702481a Silence warnings about unused parameters
Differential Revision: https://reviews.llvm.org/D56984

llvm-svn: 351888
2019-01-22 22:12:23 +00:00
Martin Storsjo 4540f5d82e Remove an unused variable
Differential Revision: https://reviews.llvm.org/D56985

llvm-svn: 351878
2019-01-22 20:50:45 +00:00
Martin Storsjo 43ed1dbfa9 Add casts to avoid warnings about implicit conversions losing precision
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
2019-01-22 20:50:42 +00:00
Martin Storsjo 94adf435ca Fix warnings about printf format strings
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
2019-01-22 20:50:39 +00:00
Martin Storsjo 495c3d3c90 Enable LLVM_ENABLE_WARNINGS when building standalone out of tree
When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.

Differential Revision: https://reviews.llvm.org/D56981

llvm-svn: 351875
2019-01-22 20:50:33 +00:00
Chandler Carruth 4a1b95bda0 Fix typos throughout the license files that somehow I and my reviewers
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
2019-01-21 09:52:34 +00:00
Chandler Carruth 57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
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
2019-01-19 10:56:40 +00:00
Chandler Carruth 469bdefd44 Install new LLVM license structure and new developer policy.
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
2019-01-19 06:14:24 +00:00
Martin Storsjo e563e08d8f [SjLj] Don't use __declspec(thread) in MinGW mode
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
2019-01-18 20:31:12 +00:00
Hans Wennborg 1fe469ae6c Bump the trunk version to 9.0.0svn
llvm-svn: 351320
2019-01-16 10:57:02 +00:00
Hans Wennborg eb60fbfdb4 Update year in license files
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
2019-01-15 15:10:32 +00:00
Daniel Cederman 17121adfa6 [Sparc] Add Sparc V8 support
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
2019-01-14 10:15:20 +00:00
Jorge Gorbe Moya 8d530b777d Revert "[Sparc] Add Sparc V8 support"
This reverts commit r350705.

llvm-svn: 350787
2019-01-10 01:08:31 +00:00
Daniel Cederman b2be18f42d [Sparc] Add Sparc V8 support
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
2019-01-09 12:06:05 +00:00
Martin Storsjo 09cf6374c1 [SEH] Add initial support for AArch64
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
2018-12-18 20:05:59 +00:00
Luke Cheeseman 357973192d [AArch64][libunwind] Unwinding support for return address signing with B Key
- 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
2018-12-17 11:43:24 +00:00
Luke Cheeseman e1a819e82d [AArch64][libunwind] Unwinding support for return address signing
- 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
2018-12-14 11:30:12 +00:00
Martin Storsjo 1ae5089765 Avoid code duplication in the SEH version of UnwindCursor::getRegisterName. NFC.
This requires making Registers_*::getRegisterName static.

Differential Revision: https://reviews.llvm.org/D55610

llvm-svn: 348981
2018-12-12 22:24:42 +00:00
Michal Gorny c790632437 [cmake] Rename append_if to avoid collision with LLVM
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
2018-12-11 15:30:04 +00:00
Martin Storsjo 4862ff8d17 [SEH] Zero-initialize EXCEPTION_RECORD and UNWIND_HISTORY_TABLE before calling RtlUnwindEx
This fixes PR39935.

llvm-svn: 348836
2018-12-11 09:53:11 +00:00
Martin Storsjo a64aa485e1 Don't export assembly functions when function visibility annotations are disabled
Patch by Peiyuan Song!

Differential Revision: https://reviews.llvm.org/D55537

llvm-svn: 348832
2018-12-11 07:34:14 +00:00
Petr Hosek 2d2e23e89b [CMake] Passthrough CFLAGS when checking the compiler-rt path
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
2018-11-14 00:09:26 +00:00
Charles Davis 869e5d1fca [CMake] Link to compiler-rt if LIBUNWIND_USE_COMPILER_RT is ON.
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
2018-10-08 18:35:00 +00:00
Luke Cheeseman 3bdf34f20e Reverting r342895
- The used builtins do not compile for pre arm v8.3a targets with gcc

llvm-svn: 342901
2018-09-24 16:36:33 +00:00
Luke Cheeseman 8284b19c76 [AArch64] Unwinding support for return address signing
- When return address signing is enabled, the LR may be signed on function entry
- When an exception is thrown the return address is inspected used to unwind the call stack
- Before this happens, the return address must be correctly authenticated to avoid causing an abort by dereferencing the signed pointer

Differential Revision: https://reviews.llvm.org/D51432

llvm-svn: 342895
2018-09-24 15:55:35 +00:00
Louis Dionne 2e667527c5 [libunwind][NFC] Suppress unused parameter warnings
Reviewers: EricWF

Subscribers: christof, chrib, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D52393

llvm-svn: 342811
2018-09-22 18:18:34 +00:00
Charles Davis 4c08654b17 [CMake] Don't use -rtlib=compiler-rt with -nodefaultlibs.
Summary:
This switch only has an effect at link time. It changes the default
compiler support library to `compiler-rt`. With `-nodefaultlibs`, this
library won't get linked anyway; Clang actually warns about that.

Reviewers: mstorsjo, rnk

Subscribers: dberris, mgorny, christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D51645

llvm-svn: 341404
2018-09-04 20:57:50 +00:00
Charles Davis 7a474b6579 [CMake] Remove variable reference that isn't used.
Summary:
This variable is never defined, so its value is always empty. Since
`libunwind` is needed to build the C++ ABI library in the first place,
it should never be linked to the C++ ABI library anyway.

Reviewers: mstorsjo, rnk

Subscribers: mgorny, christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D51644

llvm-svn: 341388
2018-09-04 17:40:26 +00:00
Charles Davis 805173c84d Export public functions implemented in assembly on Windows.
Summary:
By default, symbols aren't visible outside of the module that defines
them. To make them visible, they must be exported. The easiest way to do
that is to embed an `-export:symname` directive into the object file.

Reviewers: mstorsjo, rnk

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D51508

llvm-svn: 341232
2018-08-31 18:11:48 +00:00
Martin Storsjo a2646444d2 Fix existing code for SEH on ARM to compile correctly
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
2018-08-31 14:56:55 +00:00
Charles Davis 226570dcfc [AddressSpace] Use the macro to set hidden visibility on LocalAddressSpace.
Summary:
That attribute has no effect on Windows anyway--classes are hidden by
default.

Reviewers: mstorsjo, rnk

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D51509

llvm-svn: 341210
2018-08-31 13:41:05 +00:00
Charles Davis a7e3a6d802 Add support for SEH unwinding on Windows.
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
2018-08-30 21:29:00 +00:00
Jordan Rupprecht ca6d35b2a9 NFC: Test commit access
Testing commit access from a new machine, so using this as an opportunity to revert my old test access commit (r336006) that I never cleaned up.

llvm-svn: 339899
2018-08-16 16:55:07 +00:00
Stefan Maksimovic afc9f8ab6d [libunwind][mips] Include gcc_s for linkage
When compiling with optimizations, mips requires various helper routines(__ashldi3 and the like) contained in libgcc_s.
Conditionally include libgcc_s in the set of libraries to be linked to.

Differential Revision: https://reviews.llvm.org/D50243

llvm-svn: 339878
2018-08-16 13:40:16 +00:00
Stefan Maksimovic fe50950dac [libunwind][mips] Guard accumulator registers
Mipsr6 does not possess HI and LO accumulator registers, adjust validRegister functions to respect that.

Differential Revision: https://reviews.llvm.org/D50244

llvm-svn: 339849
2018-08-16 08:49:50 +00:00
Stefan Maksimovic 944677cd28 [libunwind][mips] Modify the __mips_fpr macro check
The __mips_fpr macro can take the value of 0 as well, change to account for that case.

Differential Revision: https://reviews.llvm.org/D50245

llvm-svn: 339848
2018-08-16 08:47:43 +00:00
Martin Storsjo f128f27874 [cmake] Add MINGW_LIBRARIES to the linker flags
This is essential when building with -nodefaultlibs.

In some CMake versions (noticed in 3.5.1), the same libraries are
picked up from CMAKE_REQUIRED_LIBRARIES in some exceptional situations
(if CXX probing failed, due to libc++ not being built yet, the libraries
from CMAKE_REQUIRED_LIBRARIES are used for linking the target library),
but not at all in other newer CMake versions (3.10).

This is similar to what already is done in libcxxabi in SVN r302760
and libcxx in SVN r312498.

Differential Revision: https://reviews.llvm.org/D50663

llvm-svn: 339642
2018-08-14 06:13:36 +00:00