| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Other source files in the source tree tend to include this header file
unconditionally. It also parses perfectly fine on ARM EHABI systems.
llvm-svn: 297175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the access to __exidx_*, dl_iterate_phdr(), etc. is specific to
the findUnwindSections() function. Right now all of the includes and
declarations related to them are scattered throughout the source file.
For example, for <link.h>, we have a full list of operating systems
guarding the #include, even though the code that uses dl_iterate_phdr()
miraculously doesn't use the same list.
Change the code so that findUnwindSections() is preceded by a block of
#ifdefs that share the same structure as the function itself. First
comes all of the macOS specific bits, followed by bare-metal ARM,
followed by ELF EHABI + DWARF.
This actually allows us to build a copy of libunwind without any
specific ifdefs for NetBSD, CloudABI, etc. It likely also unbreaks the
build of libunwind on FreeBSD/armv6, though I can't confirm.
Reviewed by: compnerd
Differential Revision: https://reviews.llvm.org/D30696
llvm-svn: 297174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exception section data that we extract for DWARF gets stored as the
offset and the number of bytes. For ARM exception info, we seem to
deviate from this by storing the number of entries. Attempt to make this
more consistent.
By storing the number of bytes, we can get rid of the EHTEntry structure
declared in AddressSpace.hpp. In UnwindCursor.hpp we already have
another structure declared for the same purpose.
Reviewed by: Keith Walker
Differential Revision: https://reviews.llvm.org/D30681
llvm-svn: 297149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function, I
still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. This approach has the advantage of getting rid
of some of those OS-specific #ifdefs. This now means that if an
operating system only provides dl_iterate_phdr(), it gets support for
unwinding on all architectures. There is no need to add more stuff, just
to get ARMv6 support.
This change is identical to r295944, except that it now adds the
necessary code to do bounds checking on PT_LOAD. The previous version of
this change lacked this, which didn't cause any problems on CloudABI,
but did break the Linux build bots. This is why I reverted it in
r295948.
Differential Revision: https://reviews.llvm.org/D30306
llvm-svn: 296991
|
|
|
|
|
|
|
|
|
|
| |
We've been having issues with using libcxxabi and libunwind for baremetal
targets because fprintf is dependent on io functions, this patch disables calls
to fprintf when building for baremetal in release mode.
Differential Revision: https://reviews.llvm.org/D30340
llvm-svn: 296135
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the change works perfectly fine on CloudABI, it fails to
work on the libcxx-libcxxabi-libunwind-arm-linux-noexceptions build bot.
Looking at the code, this may be attributed to the fact that the code
doesn't take the PT_LOAD addresses into consideration.
I will rework this change to fix that and send out an updated version
for review in the nearby future.
llvm-svn: 295948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function,
I still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. In addition to making the code a bit shorter, it
has the advantage of getting rid of some of those OS-specific #ifdefs.
This now means that if an operating system only provides
dl_iterate_phdr(), it gets support for unwinding on all architectures.
There is no need to add more stuff, just to get ARMv6 support.
Differential Revision: https://reviews.llvm.org/D28082
llvm-svn: 295944
|
|
|
|
|
|
|
|
| |
This reverts SVN r292721. Avoid the use of the GNU extension as the
preprocessor in C++11 mode requires at least one argument, and this
warning cannot be disabled, resulting in failing -Werror builds.
llvm-svn: 293257
|
|
|
|
|
|
| |
no-op the DWARF tracing macros in non-debug builds.
llvm-svn: 293008
|
|
|
|
|
|
| |
Change the case of a PRIu64 value from `long` to `uint64_t`. NFC.
llvm-svn: 292728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restore the `libunwind.h` enumeration values back to the inverted
values. This diverges from the DWARF definition of the register values.
However, this allows our header to be compatible with other unwind
implementations (e.g. HP, GNU Savannah, GCC).
The register IDs are only swapped in the header and need to be unswapped
when accessing the unwind register file. The flipped EBP and ESP only
applies on non-Apple x86 targets.
When optimizations were enabled, EBP and ESP would no longer be
equivalent. As a result, the incorrect access on Linux would manifest
as a failure to unwind the stack. We can now unwind the stack with and
without FPO on Linux x86.
Resolves PR30879!
llvm-svn: 292723
|
|
|
|
|
|
|
| |
Introduce `logDWARF` and the associated environment variable
`LIBUNWIND_PRINT_DWARF` to trace the CFI instructions.
llvm-svn: 292722
|
|
|
|
|
|
|
| |
Use the `_LIBUNWIND_LOG` macro instead of the explicit `fprintf` call.
NFC.
llvm-svn: 292721
|
|
|
|
|
|
|
|
| |
Unify the definition of `_LIBUNWIND_LOG_NON_ZERO` to make it clear what
it is defined to and make the definition unconditional. Reorder the
debug and tracing macros to be defined in the same order. NFC.
llvm-svn: 292720
|
|
|
|
| |
llvm-svn: 292719
|
|
|
|
|
|
|
| |
These are part of the EHABI specification and are exported to be available to
users. Mark them as `_LIBUNWIND_EXPORT` like the rest of the unwind interfaces.
llvm-svn: 287283
|
|
|
|
|
|
| |
bug report and the patch.
llvm-svn: 285831
|
|
|
|
| |
llvm-svn: 285636
|
|
|
|
|
|
|
|
| |
Fuchsia is a new operating system which uses libunwind as unwinder.
Differential Revision: https://reviews.llvm.org/D25899
llvm-svn: 284951
|
|
|
|
|
|
|
|
|
|
| |
This missing include seems to cause compilation failures on older MacOS
versions (< 10.9). This is because r270692 has introduced uint64_t into
config.h without including this header.
Patch from: Jeremy Huddleston Sequoia (jeremyhu@apple.com)
llvm-svn: 284125
|
|
|
|
|
|
| |
Patch by Mark Kettenis
llvm-svn: 282599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder have
a couple of pthread dependencies.
This patch makes it possible to build the whole of libunwind for a
single-threaded environment.
Reviewers: compnerd
Differential revision: https://reviews.llvm.org/D24984
llvm-svn: 282575
|
|
|
|
|
|
|
|
|
|
| |
Previously most messages included a newline in the string, but a few of
them were missing. Fix these and simplify by just adding the newline in
the _LIBUNWIND_LOG macro itself.
Differential Revision: https://reviews.llvm.org/D24026
llvm-svn: 280103
|
|
|
|
|
|
|
| |
There were several instances of libuwind (missing an "n"), dating to
the initial import of libunwind.
llvm-svn: 280086
|
|
|
|
|
|
|
|
|
| |
When the unwinder is built without WMMX support, if we encounter a WMMX register
virtual operation, early rather than attempting to continue as we would not have
saved the register set anyways. This should never come down this path, but,
just in case, help it abort more explicitly.
llvm-svn: 279941
|
|
|
|
|
|
|
|
|
|
|
| |
Some unwind code is purposedly old enough to work on previous architecutres
and they're guaranteed to never trigger in newer architectures, so we need
to add .arch directives to tell the compiler/assembler that it's fine and we
know what we're doing.
Fixes PR29149.
llvm-svn: 279871
|
|
|
|
|
|
|
|
| |
When making WMMX support optional, we uncovered the switch. Add the missing
entries. Since the entry is a break leading to a dead path, it should get
optimized out yet retain the switch overage.
llvm-svn: 279180
|
|
|
|
|
|
|
|
|
| |
This change allows building both shared and static version of libunwind
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23233
llvm-svn: 278067
|
|
|
|
|
|
|
| |
Similar to compiler-rt, ensure that we disable executable stacks for the custom
assembly.
llvm-svn: 277868
|
|
|
|
| |
llvm-svn: 277215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Thumb1 version of the code for saving and restoring the unwind
context has a few bugs which prevent it from working:
* It uses the STM instruction without writeback, which is not valid for Thumb1
(It was introduced in Thumb2).
* It only saves/restores the low 8 registers, the sp and the lr, so if a
program uses r8-r12 they will not be correctly restored when throwing an
exception.
There aren't currently any Thumb1 build-bots to test this, but we have
been successfully running the libc++abi and libc++ test suites on
Cortex-M0 models, as well as some other test suites that use C++
exceptions on a downstream version of libunwind with this patch applied.
Differential Revision: https://reviews.llvm.org/D22292
llvm-svn: 276625
|
|
|
|
|
|
|
|
| |
Obtained from FreeBSD SVN r302475
Differential Revision: https://reviews.llvm.org/D22570
llvm-svn: 276128
|
|
|
|
|
|
|
|
| |
NetBSD's system unwinder is a modified version of LLVM's libunwind.
Slightly reduce diffs by updating comments to match theirs where
appropriate.
llvm-svn: 275997
|
|
|
|
| |
llvm-svn: 275996
|
|
|
|
|
|
| |
Just a minor code cleanup. NFC.
llvm-svn: 274840
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These registers are only available on a limited set of ARM targets (those
based on XScale). Other targets should not have to pay the cost of these.
This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size.
Differential revision: http://reviews.llvm.org/D21991
Reviewers: bcraig, compnerd
Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7
llvm-svn: 274744
|
|
|
|
|
|
|
|
| |
Implement the same optimization committed under r271004 on non-EHABI,
non-SJLJ unwinder as well.
Change-Id: I7f80ed91a75d1e778b50ba87cf8fb68658a083c7
llvm-svn: 272680
|
|
|
|
|
|
|
|
|
|
| |
The whole file is guarded with #if _LIBUNWIND_ARM_EHABI, and then in the
middle we have these two blocks, which render them pretty unused. An
artefact of a refactoring it seems.
NFC.
llvm-svn: 271737
|
|
|
|
| |
llvm-svn: 271466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake.
Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed.
Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=27950
https://llvm.org/bugs/show_bug.cgi?id=27959
Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20889
llvm-svn: 271458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unwind_phase1 and unwind_phase2 allocate their own copies of unw_cursor_t buffers
on the stack. This can blow-up stack usage of the unwinder depending on how these
two functions get inlined into _Unwind_RaiseException. Clang seems to inline
unwind_phase1 into _Unwind_RaiseException but not unwind_phase2, thus creating
two unw_cursor_t buffers on the stack.
One way to work-around this problem is to mark both unwind_phase1 and
unwind_phase2 as noinline. This patch takes the less compiler-dependent approach
and explicitly allocate a unw_cursor_t buffer and pass that into unwind_phase1
and unwind_phase2 functions.
A follow-up patch will replicate this behavior for the non-EHABI and non-SJLJ
implementations.
Reviewers: jroelofs, bcraig.
Differential revision: http://reviews.llvm.org/D20320
llvm-svn: 271004
|
|
|
|
|
|
| |
NFC.
llvm-svn: 270927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r270692 seems to have broken gcc builds of libunwind. This is because
statements like:
static_assert(check_fit<Registers_or1k, unw_context_t>::does_fit,
"or1k registers do not fit into unw_context_t");
Do not work when static_assert is a macro taking two parameters, the
extra comma separating the template parameters confuses the pre-processor.
The fix is to change those statements to:
static_assert((check_fit<Registers_or1k, unw_context_t>::does_fit),
"or1k registers do not fit into unw_context_t");
Also fixed a gcc warning about a trivial un-intended narrowing.
Differential revision: http://reviews.llvm.org/D20119
llvm-svn: 270925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently libunwind is built to support cross-unwinding [1] by default, which
requires the buffers unw_context_t and unw_cursor_t to be large enough to hold
the vritual register set (VRS) of any supported architecture. This is not
desirable for some platforms where the stack usage of the unwinder needs
to be kept to a minimum (e.g. bare-metal targets). The current patch introduces
a native-only (-DLIBUNWIND_ENABLE_CROSS_UNWINDING=OFF) unwinder variant that
adopts strict sizes for the buffers unw_context_t and unw_cursor_t depending
on the target architecture.
[1] http://www.nongnu.org/libunwind/man/libunwind(3).html#section_4
Change-Id: I380fff9a56c16a0fc520e3b1d8454a34b4a48373
llvm-svn: 270692
|
|
|
|
|
|
|
|
|
| |
This unifies the definition of _LIBUNWIND_BUILD_SJLJ_APIS. It also further
generalises the definition to allow building these APIs on non-Apple targets
when `-fsjlj-excceptions` is used. The header is now clean of macros which
expand to defined checks.
llvm-svn: 267509
|
|
|
|
|
|
|
| |
Availablity.h is not used within config.h. The locations which use the
availability infrastructure already include the necessary header(s). NFC.
llvm-svn: 267365
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than use the `__assert_rtn` on libSystem based targets and a local
`assert_rtn` function on others, expand the function definition into a macro
which will perform the writing to stderr and then abort. This unifies the
definition and behaviour across targets.
Ensure that we flush stderr prior to aborting.
llvm-svn: 267364
|
|
|
|
|
|
|
|
| |
The macros were defined identically across both cases. Unify the definitions to
have a single definition for _LIBUWNIND_{HIDDEN,EXPORT} and _LIBUNWIND_LOG.
NFC.
llvm-svn: 267169
|
|
|
|
|
|
|
| |
Remove the use of undefined behaviour in the c preprocessor by always defining
the value according to the state that was being checked. NFC.
llvm-svn: 266927
|
|
|
|
|
|
|
| |
Unify the definition of the _LIBUNWIND_SUPPORT_FRAME_APIS macro. This is in
preparation to remove another instance of -Wexpansion-to-defined. NFC.
llvm-svn: 266926
|