Before this patch the `ninja check-unwind` won't rebuild the unwind library.
Reviewed By: jroelofs
Differential Revision: https://reviews.llvm.org/D85004
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.
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
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
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
- 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
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
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
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
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.
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.
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.
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!
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!
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
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
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
`__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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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!
```
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
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
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.
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
Daniel Kiss