bcm5719-llvm/libunwind/test, branch meklort-10.0.1

Reland "Enable `-funwind-tables` flag when building libunwind"

2019-12-11T01:27:04+00:00

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 938c70b86c7d2165f8c28d5700e9c1ac1263307e). 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

Revert "Enable `-funwind-tables` flag when building libunwind"

2019-12-04T07:29:15+00:00

This reverts commit b3fdf33ba6aa7ef80621696f74aaf2f6f8e1d1de. 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.

Enable `-funwind-tables` flag when building libunwind

2019-12-03T21:52:19+00:00

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

[libunwind] Adjust the signal_frame test for Arm

2019-11-19T09:58:46+00:00

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

Correctly update isSignalFrame when unwinding the stack via dwarf.

2019-11-07T22:48:35+00:00

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

[libunwind] Adjust libunwind_01.pass.cpp test for ARM EHABI

2019-10-03T17:01:04+00:00

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

Unwind: prevent unw_get_proc_info from returning stale data

2019-09-20T15:53:42+00:00

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

[libunwind] [test] Fix inferring source paths

2019-05-29T07:20:30+00:00

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

[PPC64][libunwind] Fix r2 not properly restored

2019-05-16T06:49:13+00:00

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

[CMake] Support compiler-rt builtins library in tests

2019-02-05T19:50:47+00:00

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 _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