search for: ehabi

...          Inside __gnu_unwind_pr_common after "switch (((offset & 1) << 1) | (len & 1))" control reaches default: return _URC_FAILURE. offset was == 0x808f and len was == 0xff. (((offset & 1) << 1) | (len & 1)) was == 3. 3 is an undefined descriptor as per ARM EHABI spec section 9.2. DwarfException::EmitExceptionTable Asm->EmitULEB128(TTypeBaseOffset, "@TType base offset", SizeAlign); was generating ".asciz  "\217\200"             @ @TType base offset" in .s file leading to the problem.           I would like to know whether an...

...ind 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 when not using the integrated assembler), and it seems there GCC also emits both EHABI directives and Dwarf, so I don't think we'll be able to move away from it. Since this is only relevant in debug/profiling mode, and the only problem is code size, I think this is something we can live with. Do you guys agree with it? Another issue is the usage of EH tables in C code. I bel...

...; still an issue, then -fno-unwind-table might be a solution (i.e. at llvm > assembly level, the function should be marked with nounwind and without > uwtable.) Yes, and that's what my merge request implements: http://llvm-reviews.chandlerc.com/D3079 As soon as that's in, I believe EHABI is finally in good shape to be called Beta. Since the 3.4 release I'm trying to get the EHABI and IAS support in good shape (removing the final restraints, testing a lot), for them to be enabled by default in 3.5, and I think we got it, thanks to you, Anton, Saleem and many others. cheers, --...

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. never-exceptional cases. 1. C vs. C++ We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, nothrow, etc) and uwtable,...

Dear list members, I ran into the problem that neither clang 3.4 nor current trunk versions of clang ar not usable for Objective-C on ARM. This is described in the bug report http://llvm.org/bugs/show_bug.cgi?id=18622 clang 3.3 didn't have that problem, but I also need the exception handling for ARM that is only available in recent builds, as I learned. I would like to get in touch with

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! Thank...

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

...y 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 using EHABI (I think it is), the default now is to > output full tables all the time, everywhere. This will change to be > the same as x86 soon. It does use EHABI, but at r201326: $ cat 1.cc int f() {} $ ./bin/clang++ -target arm-linux-androideabi 1.cc -c $ readelf -u 1.o 0x0 <_Z1fv>: 0x1 [cantunw...

...ato 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 are assuming C vs. C++, but it actually apply to any possibly-exceptional > vs. never-exceptional cases. > > > 1. C vs. C++ > > We have two unwind flags: nounwind, which flags functions that can't...

...(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 -backend-option -arm-enable-ehabi -backend-option -arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras -internal-isystem /usr/share/android-arm-l14-toolchain/lib/clang/3.1/include -internal-externc-isystem /usr/share/android-arm-l14-toolchain/bin/../sysroot/usr/include -o myMemcpy.s -x c myMemcpy.c Is there a flag or...

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 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, he probably h...

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

...; > 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 > -backend-option -arm-enable-ehabi -backend-option > -arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras > -internal-isystem > /usr/share/android-arm-l14-toolchain/lib/clang/3.1/include > -internal-externc-isystem > /usr/share/android-arm-l14-toolchain/bin/../sysroot/usr/include -o > myMemcpy.s -x c m...

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F:

...es by default. The third user is the backtrace which doesn't need debug or EH info (just the unwind table), and you need the -funwind-tables IFF your target doesn't have it on by default. I can only think about GPU targets that won't need any of that, but they're not using Dwarf or EHABI handlers, so we shouldn't concern about that. Embedded CPUs might want them disabled to save space, and for that we should actively disable (-fno-unwind-tables or -Os/z). The 'nounwind' attribute is set if -fexceptions is specified, or if we have > some other way of knowing the fun...

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:

...nd => emit unwind table with cantunwind > - with uwtable => emit unwind table > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind > > The cantunwind record will stop the unwinder, and cantunwind will conflict > with the stack unwind information according to EHABI. Thus, we should not > emit cantunwind for the function with uwtable. Logan, Based on the current behaviour, you only need one flag: nounwind, which should only be emitted if -fno-unwind-tables is chosen AND the function can't unwind. Also, do not assume that EHABI behaviour in LLVM is c...

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 it a try via special cmdline line -mllvm > -arm-enable-ehabi Ohhh I see, thanks for the input! > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University