When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.
The only caveat with this approach is that we are now relying on the
fact that `-L <path-to-local-libunwind>` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.
This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.
Differential Revision: https://reviews.llvm.org/D114385
Summary:
This patch marks libunwind test case signal_frame.pass.cpp as UNSUPPORTED on AIX because the AIX assembler does not support CFI directives.
Reviewed by: danielkiss, MaskRay, ldionne, libunwind
Differential Revision: https://reviews.llvm.org/D113607
Running tests for libunwind is a lot simpler than running tests for
libc++, so a simple Lit config file is sufficient. The benefit is that
we disentangle the libunwind test configuration from the libc++ and
libc++abi test configuration. The setup was too complicated, which led
to some bugs (notably we were running against the system libunwind on
Apple platforms).
Differential Revision: https://reviews.llvm.org/D111664
We should arguably have always been doing that. The state of libunwind
is quite sad, so this commit adds several XFAILs to make the CI pass.
We need to investigate why so many tests are not passing in some
configurations, but I'll defer that to folks who actually work on
libunwind for lack of bandwidth.
Differential Revision: https://reviews.llvm.org/D110872
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.
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
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
Louis Dionne