similar to: [LLVMdev] ARM EHABI support in LLVM + clang

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.

Dear all, AFAIK, ARM EHABI is not ready for both asm and obj emitter. Some people including me what to implement them. My question is, to avoid duplicate effort, does someone take charge of this part? or does anyone is already implementing this currently? BTW, any suggestion on this effort? I'm very appreciated! Thanks in advance! -- Best regards, Wen-Han Gu (Nowar) -------------- next

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

Hi, I'm investigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode: Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0) works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables

> From: Renato Golin [mailto:renato.golin at linaro.org] > > 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

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

Hello > My question is, to avoid duplicate effort, > does someone take charge of this part? or > does anyone is already implementing this currently? > > BTW, any suggestion on this effort? I'm very appreciated! There are several directions here: 1. Binary emission. Right now MC layer is text-only and depends on assembler 2. Correctness issues. It's believed that unwinding

Dear Renato and Anton, Big thanks to your help. Those references are very helpful! BTW, After I applying this patch from Logan Chien, I pass some examples on ARM assembly emission. It seems good to me. http://llvm.org/bugs/show_bug.cgi?id=7187#attach_9161 For object file emission, The first thing is making MC generate correct .ARM.exidx and .ARM.extab. I will keep tracing that. Thanks!

On May 19, 2010, at 2:37 AM, Renato Golin wrote: >> -----Original Message----- >>> My main concern is that DwarfException is not extensible at all. I >>> can't inherit from it (DwarfWriter creates it directly) and there are >>> no call backs to target-specific code (nor registration of such >>> mechanism). >> >> Why do you need this? My

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

Hello Everyone, This is my first attempt to getting used with the submission process. Trying to get the "good practice" with the coding standard, tools, mailing lists... and already a few questions: - Is it possible to "link" 2 related entries in Phabricator ? one for LLVM and one for CFE ? what's the best way of posting 2 related or dependent patches ? - I'd

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.

You may also need to use: -mllvm -enable-correct-eh-support -mllvm -arm-enable-ehabi-descriptors -Chris On Feb 4, 2013, at 3:47 PM, Abdoulaye Walsimou Gaye wrote: > On 02/04/2013 09:32 PM, Anton Korobeynikov wrote: >>> am I wrong or the ARM c++ exceptions handling does not work? >> Yes, it's still work-in-progress option disabled by default. You might >> want to give

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where

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,

Hi, I downloaded the latest NDK (r10) and compiled with the following cmd: *arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0* It still produces assembly with a call to "memcpy". Maybe the -*fno-builtin *is broken also in the latest release. Do you have some other idea that can help here? Thanks, David On Tue, Aug 5, 2014 at 11:00 AM, Jim Grosbach <grosbach at

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

Hi all, I feel that there are two problems with the existing infrastructure: * The nounwind attribute is ambiguous for (1) not throwing exceptions and (2) not performing stack unwinding. I feel that it will be better to separate this in two different attributes * There is some problem when the function has both uwtable and nounwind. Although, I think it fine to keep the current definition of