search for: libunwinder

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" ../libunwind --

Hello, We have been investigating a crash in our application that may be related to how stack frames are generated by the 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

This may be bogus, 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

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:

> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej

Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468

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

On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at least libstdc++, and I think also with Visual Studio’s implementation), so there is no dependency of anything on libc++. Similarly, we support building libc++

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

On 8 May 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++

On 28 Jul 2016, at 08:59, Renato Golin <renato.golin at linaro.org> wrote: > > On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at least libstdc++, and I think also with Visual Studio’s

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'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'd expect any issues to be largely

On Wed, Oct 22, 2014 at 11:24 AM, Jonathan Roelofs < jonathan at codesourcery.com> wrote: > I remember there being a ARM EHABI reason why this won't work, but I don't > remember the specifics. IIRC, had something to do with how c++ rtti is > required > to be handled by the catch handlers, and would mean layering problems if we > moved it. Antoine, do you remember the

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_LIMIT_MACROS -Iprojects/libunwind/src

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

On 9 May 2017, at 15:58, Mehdi AMINI <joker.eph at gmail.com> wrote: > I'd expect any 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

On 29 July 2015 at 22:20, Ben Pye <ben at curlybracket.co.uk> wrote: > Not sure if you got the other message, I think I managed to split the topic > as I wasn't subscribed to receive the previous message. This error has been > on the Raspberry Pi 2, so that's a Cortex A7 I believe, certainly ARMv7. Excellent! > I > haven't yet built trunk as on the device I run

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

[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