similar to: [LLVMdev] LibUnwind into Compiler-RT?

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,

Although this has been discussed in the past, I think that given a few conversations, it seems that it unfortunately needs to be brought up again. There seems to be some disagreement over the ideal location of the unwinder (libunwind). Currently, libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate

On 1/30/15 1:17 PM, Saleem Abdulrasool wrote: > Although this has been discussed in the past, I think that given a few > conversations, it seems that it unfortunately needs to be brought up again. > > There seems to be some disagreement over the ideal location of the > unwinder (libunwind). Currently, libunwind resides in a subdirectory of > libc++abi. There seems to be some

On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this dependence should be satisfied by the target system's unwinder, > whatever that is. If folks want to use this libunwind for their platform, > that's fine... but we should probably continue to use libgcc_s and libgcc_eh > on linux when that's the platform's unwinder.

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

On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: > Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. It's not just that, it's about making it self-contained. In a system with both gcc and llvm

On 28 July 2015 at 12:10, Schlottke-Lakemper, Michael <m.schlottke-lakemper at aia.rwth-aachen.de> wrote: > I am wondering about the meaning of the cmake flags LLVM_ENABLE_LIBCXX and LLVM_ENABLE_LIBCXXABI. Are they used to indicate that if the C/C++ compiler for building LLVM is clang, and if this clang has support for libc++ with libc++Abi, that both lib++ and libc++abi should be used

Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. On Fri, Jan 30, 2015 at 5:30 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: >

Hi, I am wondering about the meaning of the cmake flags LLVM_ENABLE_LIBCXX and LLVM_ENABLE_LIBCXXABI. Are they used to indicate that if the C/C++ compiler for building LLVM is clang, and if this clang has support for libc++ with libc++Abi, that both lib++ and libc++abi should be used (instead of linking to the default, which at least on Linux is libstdc++)? If not, what is the canonical way of

On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: > > Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. On FreeBSD, we install compiler-rt as libgcc (or, at least, symlink it to libgcc). This means that

On Fri, Jan 30, 2015 at 12:37 PM, Nick Kledzik <kledzik at apple.com> wrote: > I thought the ARM EHABI added a twist to this because it created some > upward dependency from the unwinder to libc++abi. > > Other than that, I don’t have any strong feeling where it lives. > +1 to this. If you don't break the EHABI unwinder while moving things around, I'm happy. +Dan,

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

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

Hi Renato I had the impression that Michael actually wanted the latter, like GCC > has autoconf options to change the default behaviour of the compiler > at build time. > > I may be wrong, though. yes I thought that was what he wanted because he said Are they used to indicate that if the C/C++ compiler for building LLVM is > clang > That combined with the standard cmake

> 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

On Fri, Aug 04, 2017 at 01:54:33PM -0600, Jonathan Roelofs wrote: > > > On 8/4/17 1:14 PM, Goran Mekić via llvm-dev wrote: > > On Thu, Aug 03, 2017 at 08:22:24AM -0600, Jonathan Roelofs wrote: > > > IIUC, you don't want to cross compile llvm itself (which is what those > > > instructions are for), but instead you want to *use* llvm to cross compile > >

I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi. Other than that, I don’t have any strong feeling where it lives. -Nick On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> There is a valid

I would still urge folks to consider keeping distinct functionality in separate places. Agreed, it makes more sense for the [language agnostic] unwinder to be in compiler-rt than libcxxabi -- but IMO it makes even more sense for it to be distinct. The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much

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