similar to: [LLVMdev] Compiling LibC++ with LLVM on ARM

Hi Renato, On 24 July 2015 at 04:35, Renato Golin <renato.golin at linaro.org> wrote: > Unwind-EHABI.cpp:1000:47: error: expected unqualified-id before string constant > _LIBUNWIND_EXPORT extern "C" _Unwind_Reason_Code GCC seems to be stricter than Clang about the ordering of __attribute__ (from _LIBUNWIND_EXPORT) and 'extern "C"'. You can play around

On 24 July 2015 at 15:00, Tim Northover <t.p.northover at gmail.com> wrote: > GCC seems to be stricter than Clang about the ordering of > __attribute__ (from _LIBUNWIND_EXPORT) and 'extern "C"'. Humpf, that seems to be an old thing. GCC 5.1 on my laptop cope with that just fine. :( thanks! --renato

On 24 July 2015 at 07:51, Renato Golin <renato.golin at linaro.org> wrote: > On 24 July 2015 at 15:00, Tim Northover <t.p.northover at gmail.com> wrote: >> GCC seems to be stricter than Clang about the ordering of >> __attribute__ (from _LIBUNWIND_EXPORT) and 'extern "C"'. > > Humpf, that seems to be an old thing. GCC 5.1 on my laptop cope with

Hi, I recently tried to build libcxxabi on ARM/Linux but looks like libunwind is not providing the necessary symbols needed, precisely _Unwind_SjLj_RaiseException and related functions are missing. Did anyone have any success with this before? Thanks, ismail -------------- next part -------------- An HTML attachment was scrubbed... URL:

> 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 04/12/2019 06:31 PM, Tom Stellard via llvm-dev wrote: > On 04/12/2019 04:28 PM, AiChi via llvm-dev wrote: >> Hi, >> >> I'm currently working on one of my team's project to build LLVM full clang toolchain (Clang, libcxx, libcxxabi) on a CentOS machine. >> >> Previously we compiled our codebase with llvm-toolset-7/clang++, which by default takes stdlibc++

Hi Marshal, ARM has recently moved the buildslave from single test to with/without exception: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux-noexceptions but both slaves have the same error that wasn't there before: ******************** TEST 'libc++ ::

Hi cschen, It seems that libunwind (the one included in libcxxabi) is mandatory at the moment. Use the second build command instead: $ CROSS_COMPILING=arm ENABLE_LIBUNWIND=1 ./scripts/compile-all.sh Logan On Tue, Oct 7, 2014 at 5:32 PM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > After do "sudo apt-get update", the following are pass. > > Install the

# Everything is done on Mac OS X 10.8.4, with llvm/clang/libc++/libc++abi built from source this morning # totclang is an alias for the built clang. $ export LLVM=/Sources/LLVM $ export LIBCXX=$LLVM/libcxx $ export LIBCXXABI=$LLVM/libcxxabi $ totclang -std=c++11 -stdlib=libc++ -I $LIBCXX/include -fsanitize=undefined ubsan.cpp -L $LIBCXX/lib -L $LIBCXXABI/lib -lc++abi $

I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. The configuration is the following: LIBCXX_HAS_MUSL_LIBC=ON LIBCXX_HAS_GCC_S_LIB=OFF CLANG_DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64

On 15 March 2014 17:06, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > I would like to know what do you mean by "commoning them up"? Hi Logan, That'd be reducing ARM directives in favour of CFI, but as I said (and you too), GNU compatibility will probably be an issue for a very long time. > For the space issue, I personally don't think this is a big issue.

Hi, I'm currently working on one of my team's project to build LLVM full clang toolchain (Clang, libcxx, libcxxabi) on a CentOS machine. Previously we compiled our codebase with llvm-toolset-7/clang++, which by default takes stdlibc++ to compile and link. And now we'd like to switch to use LLVM clang with libc++. I have built libc++ and libc++abi from source (5.0.1 release) and set

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 13:47, Evgeniy Stepanov <eugenis at google.com> wrote: >> Hm, I see that -funwind-tables on arm-linux-androideabi target >> replaces this "cantunwind" with a proper unwind table. >> Hence http://llvm-reviews.chandlerc.com/D2762. > > If Android is

Clang optimizes code by replacing some parts with efficient library functions. For example the following code: for (i=0;i<size;++i) dest[i]=src[i]; will be compiled to (target=ARM assembly): bl __aeabi_memcpy(PLT) The compile cmd: /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e

So I started prototyping remote testing for libcxx over the weekend: https://github.com/jroelofs/libcxx/tree/remote_test The SSHExecutor isn't quite finished yet, but this should give an idea of what I've got in mind. Does this look generic enough to work for other projects under the llvm-umbrella (LNT, test-suite, compiler_rt, libcxxabi, etc)? Are there use cases that you see

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly

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,

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

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>