similar to: [LLVMdev] Recent libc++ failures due to libunwind

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

Hi, I've managed to left it out. I just realized it myself while installing a test host for upcoming C3U6. I don't know how i managed to leave it out, but i did and now it's fixed (no one has been complaining tho which makes me wondering if there even is any CentOS-3/ia64 installations :) files: updates/ia64/RPMS/libunwind-0.97-4.ia64.rpm -- Pasi Pirhonen - upi at iki.fi -

The latest TOT of libunwind fails for me when I build UnwindRegistersSave.S for the Mips. My copy of clang uses a 2.25 binutils Mips assembler. This is the message I get: "/home/rich/ellcc/bin/mips-elf-as" -o /tmp/UnwindRegistersSave-a2c974.o -EL /tmp/UnwindRegistersSave-545450.s src/UnwindRegistersSave.S: Assembler messages: src/UnwindRegistersSave.S:99: Error: opcode not

On 09/27/2015 06:41 PM, Vasileios Kalintiris wrote: > Hi Richard, > > Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2". > > Which version of the ISA did you specify when you used the integrated assembler? > > Thanks, > Vasileios > > Hi

Hi Logan, So, I just realised clang 3.8 comes with an unwind.h which doesn't have _URC_OK defined (introduced in r262178, just after 3.8 split). But on that commit, the personality routine depends on it for EHABI calls, which is defined by default on ARM environments. The end result is that I can only use Clang 3.9+ to compile libunwind 3.9+.

CentOS Errata and Bugfix Advisory 2016:0203 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-0203.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 6e1e40010c7725c9c2fe9e40cb6f560c02cd2d9832a779c817dc46d39375ca8b libunwind-1.1-5.el7_2.2.i686.rpm

Hi Talin, > I'm using the LLVM exception handling intrinsics, along with a custom > personality function, to do exception handling and it is working well. > Now, I would like to add the ability to produce a human-readable stack > backtrace for exceptions which are not caught (or rather, which are > caught by some top-level function which prints the exception's stack

On 16 April 2016 at 01:44, Zhao, Weiming via cfe-dev <cfe-dev at lists.llvm.org> wrote: > I'm building libunwind for ARM baremetal using clang. > I notice that __ELF__ is used in libunwind and the macro is only defined for > Linux target on ARM. > Should we also predefine that for arm-none-eabi target? Do you mean in Clang's ARMTargetInfo::getTargetDefines() ? I think

On 18 April 2016 at 16:18, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > This doesn't look like something ACLE specific (I can't find it in the ACLE doc). Sorry, I didn't mean it was ACLE, only that you guys were fiddling with macros. :) > This seems to be a generic macro. I think it would make sense to define it > if we know we're emitting ELF. Since the

> > Should the integrated assembler be enabled by default for the Mips? > > Not yet. There's a number of quiet mis-assembly bugs at the moment. The > plan is to switch it on once it's good enough for the Linux kernel and see what > bug reports come back. Having said this, we had our first successful boot of the Linux kernel build with clang and -fintegrated-as today.

On 18 April 2016 at 16:33, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > Doing a grep "eabi" * -R | grep darwin in llvm I found the test divmod-eabi.ll > which uses the triple armv7-apple-darwin-eabi. What format does that have? Certainly not ELF. :) But I didn't mean "has eabi on triple", but "is in none-eabi mode", which may have to check a

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 Nick! In r207467 you added code(libunwind: DwarfInstructions.hpp): assert(lastReg <= (int)cieInfo.returnAddressRegister && "register range does not contain return address register"); for (int i = 0; i <= lastReg; ++i) { ..... else if (i == (int)cieInfo.returnAddressRegister) There is misprint here: lastReg should be >=

Hi All, We recently migrated to llvm 9 from gcc -7 and found that the stack usage is more like 5K in the below function getInfoFromDwarfSection() @ line : 1484 <https://github.com/llvm-mirror/libunwind/blob/master/src/UnwindCursor.hpp#L1484> With our analysis and found that "typename CFI_Parser<A>::PrologInfo prolog" local data is taking up almost 4K space. So we

I'm using the LLVM exception handling intrinsics, along with a custom personality function, to do exception handling and it is working well. Now, I would like to add the ability to produce a human-readable stack backtrace for exceptions which are not caught (or rather, which are caught by some top-level function which prints the exception's stack trace). I'm assuming that the way to

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

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

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

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