search for: libunwind's

Hello. I was trying to compile https://github.com/llvm/llvm-project/tree/master/libunwind using: - MSVC - Clang I wasn't able to configure this project for using MSVC (directly or via clang-cl): >cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libu...

...he JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack. Here is what the stack trace looks like on MacOSX 10.6 : 0 libSystem.B.dylib 0x00007fff87297bdb libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE(libunwind::LocalAddressSpace&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::CIE_Info*) + 75 1 libSystem.B.dylib 0x00007fff87298795 libunwind::CFI_Parser<libunwind::LocalAddressSpace&...

...but do you have: llvm::JITExceptionHandling = true; for the code that generates the dynamic code? It has been a while, but I don't recall what will happen when dynamic code, generated with jit exception handling turned off, invokes libraries which in turn try to unwind the stack via the libunwind api. However given that you say the code works with 2.8, my concern maybe irrelevant. Personally I have a feeling that with llvm::JITExceptionHandling turned off, the unwinding should correctly "pass through" the generated code. With llvm::JITExceptionHandling turned on, a potential cras...

...Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. >> >> I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. >> >> >> Are you sure that libunwind being built witho...

...Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. >> >> I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. >> >> >> Are you sure that libunwind being built witho...

...vm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468 <https://bugs.llvm.org/show_bug.cgi?id=38468>. >> >> I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294 <https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294>, if the compiler “s...

There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. However, the CMake check fails with the following error: ``` ld.lld: err...

...o with Visual Studio’s implementation), so there is no dependency of anything on libc++. Similarly, we support building libc++ with other compilers (in FreeBSD, we currently build it with gcc 6.1 for RISC-V, for example, where the LLVM toolchain is not quite useable). > > The same applies to libunwind, to an even greater degree (where libc++ implements a standard API, libunwind implements a standard ABI). I think the dependencies of lib* in LLVM are more conceptual than version lock, but they're still there. I agree with you in all other points, mind you, but RT needs an unwind library as...

On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > Hi, > > > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > Just as Shoaib said, libunwind only is useful in environments > > that use > > the Itanium C++ ABI - there's really no use for it in an MSVC > > context > > (either using MSVC or clang-cl to compile it). > > > > The particular linker error comes from the fact...

...2017, at 20:51, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>: > Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it. I have recently been working on bring-up for libc++ and libunwind on a new platform and the integration of libunwind with the LLVM build system is already annoying (you can’t build it unless you have a working C++ standard library implementation for your target, even t...

...ual Studio’s implementation), so there is no dependency of anything on libc++. Similarly, we support building libc++ with other compilers (in FreeBSD, we currently build it with gcc 6.1 for RISC-V, for example, where the LLVM toolchain is not quite useable). > > > > The same applies to libunwind, to an even greater degree (where libc++ implements a standard API, libunwind implements a standard ABI). > > I think the dependencies of lib* in LLVM are more conceptual than version lock, but they're still there. > > I agree with you in all other points, mind you, but RT needs...

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that > it's not possible to test libunwind on arm-linux when using compiler_rt? Yeah, it's hard and clumsy, not impossible. Basically, I want to avoid requiring people to link against libunwind+rt+libcxxabi if all they need is libcxx or rt. >> An alternative to fix the libc++ tests on ARM would be to require >> Compiler-...

I've started the process of bringing LLVM's libunwind into the FreeBSD base system[1]. As part of that process we've tested building the approximately 25,000 third party software packages in the FreeBSD ports collection against a modified FreeBSD with libunwind included[2]. Of course, I wouldn't expect much in the way of build failures -- I...

...ber the specifics? > For a complete implementation, the arm-defined PRs (__aeabi_unwind_cpp_pr[0-2]) need to call the functions in 8.4.2 in phase 2, which are in libc++abi. In particular, as you mention, __cxa_type_match needs the rtti info. That said, currently this part is not implemented in libunwind, among others because clang never generates code that uses arm-defined PRs for exceptions and cleanup, only for trivial frame unwinding (it always uses __gxx_personality_v0 for exceptions/cleanup), so I don't think today libunwind depends on libc++abi, except for the recent patch for _Unwind_Ba...

I'm building LLVM with Clang, LLD, compiler-rt, libunwind, libcxx and libcxxabi. I'm using GCC 7.1.1 and binutils 2.28.0 to build. The compilation is aborted during libunwind build due to gcc not being able to parse libcxx's __config: /usr/bin/cc -DLLVM_BUILD_GLOBAL_ISEL -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC...

Hi, During last 2-3 days I started to get some new regressions from the libc++ testsuite, one of them is std/containers/sequences/list/list.modifiers/insert_iter_iter_iter.pass.cpp . When run under gdb this seems to be a crash under libunwind code: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff73d00ce in unw_get_proc_info (cursor=0x7fffffffd940, info=0x7fffffffd520) at ../projects/libunwind/src/libunwind.cpp:237 #2 0x00007ffff73d4b83 in _Unw...

...y CI system to be able to cache this. > Also if you're issue is archiving a lot of build artifacts, the constant cost of the checkout isn't gonna matter that much. > Finally, the read-only individual repo can still be used by CI, which address this entirely. If we want to pull in new libunwind fixes from upstream, we’ll also pull in irrelevant LLVM, clang, lldb, lld, and so on changes. This translates to extra bandwidth and storage requirements for *every* copy of the libunwind repo that we need. If we follow the monorepo approach downstream and merge these independent repos, then we a...

...but a generation bug (of the > unwind information). I do find the crash you experience curious, but it's > not something I have had occur here. Unfortunately I can't say I have great > experience with the ARM unwind information, but really got to that > conclusion by eliminating libunwind as GCC does generate unwind information > that results in PC being restored. Yeah, that's where unwinding gets tough... Unwinding the stack, either for debug or profile purposes, is composed of two independent parts: the compiler (generating prologues/epilogues, as well as unwind tables) a...

So, I remember we discussed this earlier this year, but I can't find the thread. The idea is to move libunwind into compiler-rt for the simple reasons below: 1. Unwinding is not exclusive to C++, nor exception handling. 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt (maybe eh isn't needed, but it was there for libgcc). 3. Testing the libunwind with libc++ on ARM is not possible,...

[Cross-post to llvm-dev to make sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of supported use cases for building the runt...