This is in preparation for adding support for N32 unwinding which reuses
the newabi register class.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D41842
llvm-svn: 322093
Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.
It supports:
- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41386
Now builds with LIBUNWIND_ENABLE_CROSS_UNWINDING=ON should
work.
llvm-svn: 321680
For builds that only target one architecture, this was required to
be an exact match, while it previously required the allocation to be
strictly larger than the largest concrete one. Requiring it to be
larger than on equal should be enough.
This makes it more straightforward to update _LIBUNWIND_CONTEXT_SIZE
and _LIBUNWIND_CURSOR_SIZE.
llvm-svn: 321679
Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.
It supports:
- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41386
llvm-svn: 321667
Instead, cast them to `void *` which has a portable format string syntax
of `%p`.
This fixes a -Wformat error when building libunwind.
llvm-svn: 321469
Right now, ARM EHABI unwind on bare metal expects to find the symbols
__exidx_start and __exidx_end defined, and uses those to locate
the EH tables. However, DWARF unwind on bare metal expects to find
dl_iterate_phdr, which, although possible to provide, is inconvenient
and mildly absurd.
This commit provides feature parity with ARM EHABI unwind by looking
for symbols __eh_frame_start, __eh_frame_end, __eh_frame_hdr_start
and __eh_frame_hdr_end, denoting the start and end of the sections
with corresponding names. As far as I know, there is no de jure or
de facto ABI providing any such names, so I chose the obvious ones.
The .eh_frame_hdr support is optional for maximum flexibility and
possible space savings (e.g. if libunwind is only used to provide
backtraces when a device crashes, providing the .eh_frame_hdr, which
is an index for rapid access to EH tables, would be a waste.)
The support for .eh_frame_hdr/DWARF index in the first place is
conditional on defined(_LIBUNWIND_SUPPORT_DWARF_INDEX), although
right now config.h will always define this macro.
The support for DWARF unwind on bare metal has been validated within
the ARTIQ environment[1].
[1]: https://m-labs.hk/artiq/
llvm-svn: 321445
Use the `_LIBUNWIND_LOG` and `_LIBUNWIND_LOG0` macros instead of
the explicit `fprintf` call.
This was previously done in r292721 as a cleanup and then reverted
in r293257 because the implementation in r292721 relied on a GNU
extension. This implementation avoids the use of an extension
by using a second macro instead, and allows to avoid the dependency
on fprintf if _LIBUNWIND_BARE_METAL is defined.
llvm-svn: 321441
This supports the soft-float ABI only and has been tested with both clang
and gcc on FreeBSD.
Reviewed By: sdardis, compnerd
Differential Revision: https://reviews.llvm.org/D38110
llvm-svn: 320528
This supports using a newer libunwind with an older installation of LLVM
(whose cmake modules wouldn't have add_llvm_install_targets).
llvm-svn: 320163
This follows the setup used by other runtimes and is expected by
the lit configuration.
Differential Revision: https://reviews.llvm.org/D40820
llvm-svn: 319830
This gains us the install-unwind-stripped target, to perform stripping
during installation.
Differential Revision: https://reviews.llvm.org/D40685
llvm-svn: 319498
This is useful in cases where we only build static library and
libunwind.a is combined with libc++abi.a into a single archive in which
case we don't want to have libunwind.a installed separately. The same
option is already provided by libcxx CMake build.
This change also adds the install-unwind target for consistency with the
libcxxabi and libcxx CMake build.
Differential Revision: https://reviews.llvm.org/D40195
llvm-svn: 318569
If the linker chose to store the full section name instead of truncating
it, this field doesn't contain a truncated name, but an offset into
the string table of the binary. The string table isn't loaded/mapped
into memory during runtime though, so it's not possible to read the
full section name, unless we try to locate the DLL/EXE on disk that
the HMODULE corresponds to and load that manually.
Due to this, lld now always prefers writing a truncated section name
for sections that will be mapped at runtime, even when debug info is
enabled.
Differential Revision: https://reviews.llvm.org/D39918
llvm-svn: 318446
This didn't require any further changes to libunwind as long as win64
in general is handled correctly.
Differential Revision: https://reviews.llvm.org/D39632
llvm-svn: 318383
The previous definition of _LIBUNWIND_HIGHEST_DWARF_REGISTER seems
to be a copy of the ARM64 value (introduced in SVN r276128); since
the code actually hasn't compiled properly for arm in dwarf mode
before, this hasn't actually been used. Set it to the correct value
based on the UNW_ARM_* enum values.
The iwmmx control variables have to be made mutable, since they are
touched from within getRegister (which previously wasn't const), and
getRegister is used on a const Registers object in DwarfInstructions.hpp.
Differential Revision: https://reviews.llvm.org/D39251
llvm-svn: 317192
This matches the original libunwind API. This also unifies the
type between ARM EHABI and the other configurations, and allows
getting rid of a number of casts in log messages.
The cursor size updates for ppc and or1k are untested, but
unw_proc_info_t shrinks by 4 uint64_t units on i386 at least.
Differential Revision: https://reviews.llvm.org/D39365
llvm-svn: 316942
This restores the previous behaviour of the Registers_* classes
after SVN r316745.
Differential Revision: https://reviews.llvm.org/D39382
llvm-svn: 316843
Clang doesn't currently support building for windows/x86_64 with
dwarf by setting command line parameters, but if manually modified
to use dwarf, we can make libunwind work in this configuration
as well.
Also include i386 in the docs when adding this as a supported
configuration; libunwind already works for i386 windows, but
can fail due to an issue unrelated to windows itself.
Differential Revision: https://reviews.llvm.org/D38819
llvm-svn: 316747
This avoids having to keep the same information duplicated in multiple
places.
Adjust _LIBUNWIND_HIGHEST_DWARF_REGISTER to actually have the value
of the highest used register and only use the value
_LIBUNWIND_HIGHEST_DWARF_REGISTER + 1 (kMaxRegisterNumber + 1) for
allocating the savedRegisters array.
Differential Revision: https://reviews.llvm.org/D39281
llvm-svn: 316745
For many targets setting -fno-exceptions will prevent unwinding tables from
being generated for the test programs. As libunwind depends on the tables to
unwind the stack several tests will fail.
This change always adds -funwind-tables so that even when -fno-exceptions
is set unwind tables are generated.
fixes PR33858
Differential Revision: https://reviews.llvm.org/D37484
llvm-svn: 316657
This was missed in SVN r274744 when the WMMX part was made optional;
when made optional, some struct fields were reordered, which caused
the total struct size to grow due to padding/alignment.
llvm-svn: 316559
Most other cases that touch savedRegisters[reg] have got this check,
but these three seemed to lack it.
Differential Revision: https://reviews.llvm.org/D39206
llvm-svn: 316415
This requires _WIN32_WINNT >= 0x0600.
If someone wants to spend effort on supporting earlier versions,
one can easily add another fallback implementation based on
critical sections, or try to load SRW lock functions dynamically.
This makes sure that the FDE cache is thread safe on windows.
Differential Revision: https://reviews.llvm.org/D38704
llvm-svn: 316364
This avoids a hack for making it a no-op for windows.
Also explicitly check for _WIN32 instead of assuming it.
Differential Revision: https://reviews.llvm.org/D39156
llvm-svn: 316300
If there is no binary search table computed, the FDECount encoding is
DW_EH_PE_omit. Do not attempt to read the FDECount in such a situation
as we will read an incorrect value. binutils only writes out the
FDECount if the encoding is not DW_EH_PE_omit.
llvm-svn: 316224
libunwind is known to work on FreeBSD i386, amd64 (x86_64) and arm64.
It is the unwinder provided by the base system on all of those
architectures.
While here sort the OS list.
Differential Revision: https://reviews.llvm.org/D38900
llvm-svn: 315814
In practice, with code built with clang, there are still unresolved
issues with DW_CFA_GNU_args_size though.
Differential Revision: https://reviews.llvm.org/D38679
llvm-svn: 315498
Rather than hardcode the flag and check if the compiler supports it, use
the CMake property to get the right flag spelling for the compiler.
This makes it generally more portable.
llvm-svn: 314834
That commit incorrectly expanded the assumption that defined(__APPLE__)
implies SjLj exception handling, which only is true within ARM
code sections.
llvm-svn: 314695
This moves the definition of the internal helpers
`__Unwind_SjLj_GetTopOfFunctionStack` and
`__Unwind_SjLj_SetTopOfFunctionStack` into `Unwind-sjlj.c`. These are
not extra functions specific to Apple, but rather are internal
implementation details of SjLj support in the LLVM libunwind
implementation.
This allows us to remove the internal header unwind_ext.h, as these
functions are not meant to be used as SPI either. Because they are
static, they will be given implicit hidden visibility, but due to the
simplicity should get fully inlined into the actual use.
Use the C11 standard static TLS annotation (`_Thread_local`) if
possible, otherwise, use the Windows specific `__declspec(thread)` when
targeting Windows or the GNU `__thread` extension. In theory, it should
be possible for this implementation to use a `pthread_setspecific` and
`pthread_getspecific` on platforms with pthreads or `SetFlsValue` and
`GetFlsValue` on Windows for non-static TLS. However, static TLS tends
to be significantly faster, so we really should prefer that over the
dynamic TLS approach. On Apple environments, when not building for the
loader (dyld), use the pre-allocated TLS slot in the loader rather than
the local static TLS variable.
Note that the un-threaded support of libunwind is still present as
before, however, it is unsafe to use in a threaded environment as the
cleanup stack may be mutated incorrectly due to lack of locking across
threads. In the static TLS model, the lock is unneeded as each thread
of execution retains its own copy of the cleanup stack.
Take the opportunity to clean up the comment block, removing the iOS
specific note as the SjLj implementation can be used outside of the
context of iOS. Convert the rest of the explanation to a doxygen style
comment block.
llvm-svn: 314632
When SJLJ exceptions are used, those functions aren't used.
This fixes build failures on ARM with SJLJ enabled (e.g. on armv7/iOS)
when built using the CMake project files.
Differential Revision: https://reviews.llvm.org/D38249
llvm-svn: 314197
This makes it match the definition used within llvm and in libgcc,
we previously got the wrong layout in 64 bit environments.
Differential Revision: https://reviews.llvm.org/D38247
llvm-svn: 314196
The changes in r297174 moved the #include of <link.h> on FreeBSD (and
probably other systems) inside of the open 'libunwind' namespace
causing various system-provided types such as pid_t to be declared in
this namespace rather than the global namespace. Fix this by moving
the relevant declarations before the 'libunwind' namespace is opened,
but still using the cleaned up declarations from r297174.
Reviewed By: ed, compnerd
Differential Revision: https://reviews.llvm.org/D38108
llvm-svn: 313920
John Baldwin