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
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
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
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
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.
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
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
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
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
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.
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`.
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++`.
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
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
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
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
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
Move the definition of Elf_Addr typedef to the only place it is used, to avoid:
```
llvm-project/libunwind/src/AddressSpace.hpp:501:28: warning: unused typedef 'Elf_Addr' [-Wunused-local-typedef]
```
when compiling for Android with _LIBUNWIND_ARM_EHABI defined and
_LIBUNWIND_SUPPORT_DWARF_UNWIND not defined.
Patch by Joel Klinghed!
llvm-svn: 372427
If unwind info is not available at the current IP, unw_get_proc_info should
return a zero-filled structure rather than the info of the previous IP.
This change also makes unw_get_proc_info return UNW_ENOINFO instead of
UNW_ESUCCESS.
Patch by Amanieu d'Antras!
llvm-svn: 372407
r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.
Differential Revision: https://reviews.llvm.org/D65098
llvm-svn: 366734
This is a small fix for https://reviews.llvm.org/D64996. The types of
w0 and w1 in _Unwind_VRS_Get must be uint64_t, not uint32_t.
Committing as obvious.
llvm-svn: 366701
Summary:
The function Unwind-EHABI.cpp:_Unwind_VRS_Pop loads the saved values of
64-bit FP registers as two 32-bit words because they might not be
8-byte aligned. Combining these words into a 64-bit value has to be
done differently on big-endian platforms.
Reviewers: ostannard, john.brawn, dmgreen
Reviewed By: ostannard
Subscribers: kristof.beyls, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64996
llvm-svn: 366587
Summary:
The function getByte is dependent on endianness and the current
behavior is incorrect on big-endian targets.
This patch fixes the issue.
Reviewers: phosek, ostannard, dmgreen, christof, chill
Reviewed By: ostannard, chill
Subscribers: chill, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64402
llvm-svn: 365505
Summary:
The AArch64 version of the libunwind function which restores the
CPU state and resumes execution is not interrupt-safe. It restores
the target value of SP before loading the floating-point registers
from the context struct, but that struct is allocated on the stack
which is being deallocated. This means that if an interrupt occurs
during this function, and uses a lot of stack space, it could
overwrite the values about to be loaded into the floating-point
registers.
This patch fixes the issue.
Patch by Oliver Stannard.
Reviewers: phosek, chill
Reviewed By: chill
Subscribers: chill, javed.absar, kristof.beyls, christof, LukeCheeseman, pbarrio, olista01, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63006
llvm-svn: 363545
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.
This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.
Differential Revision: https://reviews.llvm.org/D62090
llvm-svn: 362048
Fix two issues that caused libcxx source path not to be inferred
correctly when not specified explicitly:
1. get_lit_conf() uses default value only if the lit variable is set
to None. Due to the mehod of substituting lit.site.cfg, they were
"" rather than None when unset, effectively causing the default never
to apply. Instead, use 'or' construct to use the default whenever
get_lit_conf() returns a false value.
2. If os.path.join() is given a component starting with '/', it takes
it to be an absolute path and ignores everything preceding it.
Remove the slash to correctly append subdirectory.
With these two fixes, libunwind tests start working on NetBSD buildbot
again.
Differential Revision: https://reviews.llvm.org/D62005
llvm-svn: 361931
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
Clang integrated assembler was unable to build libunwind PPC32 assembly code,
present in functions used to save/restore register context.
This change consists in replacing the assembly style used in libunwind source,
to one that is compatible with both Clang integrated assembler as well as
GNU assembler.
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D61792
llvm-svn: 360862
This change makes each unwind step inspect the instruction at the
return address and, if needed, read r2 from its saved location and
modify the context appropriately.
The unwind logic is able to handle both ELFv1 and ELFv2 stacks.
Reported by Bug 41050
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D59694
llvm-svn: 360861
calls into the pthread library use weak symbols.
This option allows libpthread to be a weak dependency rather
than a hard one.
Differential Revision: https://reviews.llvm.org/D60285
llvm-svn: 360610
This change introduces support for building libuwind. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60370
llvm-svn: 359804
For builds with SJLJ, there is no __unw_getcontext symbol. On Windows,
the weak alias macro also expands to a dllexport directive, which fails
if the symbol doesn't exist.
Differential Revision: https://reviews.llvm.org/D60251
llvm-svn: 357711
This is not necessary for ELF since .globl and .weak are mutually
exclusive, but is necessary for Mach-O otherwise the symbol isn't
visible externally.
Differential Revision: https://reviews.llvm.org/D60245
llvm-svn: 357671
libunwind defines the _Unwind_* ABI used by libc++abi. This ABI is a
stable quasi-standard common between multiple implementations such as
LLVM and GNU. The _U* symbol name space is also safely within the symbol
name space that standard C & C++ reserve for the implementation.
Futhermore, libunwind also defines several unw_* symbols, and references
these from the _Unwind_* entry points so the standard/reserved part of
the ABI is dependent on the unw_* part of the ABI. This is not OK for a
C or C++ implementation. The unw_* symbols are reserved for C and extern
"C" used by application code.
This change renames each unw_* function to __unw* and adds a weak alias
unw_* to keep the public <libunwind.h> ABI unchanged for backwards
compatibility. Every reference to unw_* in the implementation has been
changed to use __unw* so that if other unw_* definitions are in force
because nothing uses <libunwind.h> in a particular program, no _Unwind*
code path depends on any unw_* symbol. Furthemore, __unw_* symbols are
hidden, which saves PLT overhead in the shared library case.
In the future, we should cconsider untangling the unw_* API/ABI from the
_Unwind_* API/ABI. The internal API backing the _Unwind_* ABI
implementation should not rely on any nonstandard symbols not in the
implementation-reserved name space. This would then allow separating the
_Unwind_* API/ABI from unw_* entirely, but that's a more substantial
change that's going to require more significant refactoring.
Differential Revision: https://reviews.llvm.org/D59921
llvm-svn: 357640
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
If we're not in a standalone build, this variable should be already
set, so there's no need to set it again or to cache it.
Differential Revision: https://reviews.llvm.org/D57993
llvm-svn: 353915
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
While Clang automatically generates the code for placement new,
g++ doesn't do that so we need to provide our own definition.
Differential Revision: https://reviews.llvm.org/D57455
llvm-svn: 352966
This is unfinished, unused and incomplete. This could be brought back in
the future if there's a desire to build a more complete implementation,
but at the moment it's just bitrotting.
Differential Revision: https://reviews.llvm.org/D57252
llvm-svn: 352965
Louis Dionne