search for: armexcept

> Is it safe to say the MC work provides a (new) foundation for > implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC > work? The latter. MC stuff helps somehow though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Mon, Sep 27, 2010 at 09:14:05AM -0700, Jason Kim wrote: > On Mon, Sep 27, 2010 at 8:50 AM, Dennis Taul <dtaul at codeaurora.org> wrote: > > > > I am new to LLVM but have perused the code alongside using llvm-gcc > > and CLANG to build ARM EABI objects. > > > > Based on this superficial analysis it appears that LLVM currently does > > not support the

...on .fnstart/.fnend symbols and others) is conditional *only* to the existence (or not) of an exception handling class being loaded (EHABI, Dwarf). Which means that, we can't disable the EH on a per-function basis. We'll have to change the way these symbols are emitted, at least when using ARMException, so that we can emit the tables and honour the uwtable on a per-function basis. Again, this is a requirement for problem 1, but it'd need to be fixed after 3. 3. Unwinding code Currently, even when no exception handling are needed, the exception code is used to generate Dwarf unwinding d...

...ols and others) is conditional *only* to the existence > (or not) of an exception handling class being loaded (EHABI, Dwarf). Which > means that, we can't disable the EH on a per-function basis. > > We'll have to change the way these symbols are emitted, at least when using > ARMException, so that we can emit the tables and honour the uwtable on a per-function basis. > > Again, this is a requirement for problem 1, but it'd need to be fixed after 3. > > > 3. Unwinding code > > Currently, even when no exception handling are needed, the exception code is &gt...

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

Hello, Renato > Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong... Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With

...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 ARMException and DwarfCFIException are concerned, which is the ones we're discussing about. I'm beginning to think that there is no reason at all to have an uwtable attribute, given that the -funwind-tables is propagated to the back-end AND if we emit the table for one function we should do it for a...

Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang:

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

...king. 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). To change that in line with AsmWriter would be a major change and passing a ARMException reference through AsmWriter would pass the object through many places that are not concerned with it. A simple registration mechanism (DE->registerTargetCode-thingy) would be the least change and more direct approach, but it's damn ugly. ;) Apart from that, the format of the table and t...

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>

...ble in the LLVM reference manual? - What is the possible expected behavior when uwtable is used with nounwind If we have some decision, I am willing to write the patch. :-) Footnotes --------- See <llvm>/lib/CodeGen/VirtRegMap.cpp line 290 See <llvm>/lib/CodeGen/AsmPrinter/ARMException.cpp line 65 See <libc++abi>/test/test_vector3.cpp On Sat, Feb 15, 2014 at 11:36 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 15 February 2014 11:38, Evgeniy Stepanov <eugeni.stepanov at gmail.com> > wrote: > > I'd love to hear more details....

...ry libLLVMSelectionDAG.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/CodeGen/SelectionDAG' make[3]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/CodeGen/AsmPrinter' llvm[2]: Compiling TargetTransformInfo.cpp for Release+Asserts build llvm[3]: Compiling ARMException.cpp for Release+Asserts build llvm[3]: Compiling InductiveRangeCheckElimination.cpp for Release+Asserts build llvm[2]: Compiling Trace.cpp for Release+Asserts build llvm[3]: Compiling AddressPool.cpp for Release+Asserts build llvm[2]: Compiling TypeBasedAliasAnalysis.cpp for Release+Asserts buil...