[PATCH][cxxabi] ARM EHABI zero-cost exception handling for libc++abi

[Jonathan Roelofs]

Logan,

On 4/13/14, 9:37 AM, Logan Chien wrote:
> Hi Jonathan,
>
> Thanks for your reply.
>
>  >  *  One thing that immediately jumps out at me as missing from this
>  >     implementation are the __aeabi_unwind_pr{0,1,2} functions, which
>  >     are necessary to unwind more kinds of frames that the backend spits out.
>
> Yes.  I have only implemented the personality function in this patch.  Thus, we
> still have to link with libgcc at the moment.

Is it going to work having half of the unwinder come from libgcc and the other 
half come from libcxxabi+libcxx? I was under the impression that support had to 
be all or nothing...

 > AFAICT, following important functions are missing:
>
> - __aeabi_unwind_pr{0,1,2}()
> - _Unwind_RaiseException(), _Unwind_GetLanguageSpecificData(),
> _Unwind_GetRegionStart()
> - _Unwind_VRS_{Get,Set}()
> - __gnu_unwind_frame()
If these two implementations can be merged, then we'll get all but the last one 
for 'free'. I believe the last one is an implementation detail of libgcc, and is 
not part of the unwinder's public api, so I don't think it needs implementing.

To reduce my own merge anxiety, I'd like to get Nico's patches upstreamed too. 
I'll focus more on that in the next couple of days.
>
>  >  *  Also, I believe there might be a catch clause indexing bug as fixed in [2]
>  >     (though maybe that change should be under #if LIBCXXABI_ARM_EHABI ?).
>
> It seems that I am using different way to handle the filter type index, thus it
> won't be a problem.
>
>  >  *  A bunch of the _Unwind_* functions are done up as static inline... would be
>  >     nicer to use the unwind cursor abstraction to help keep down #ifdef
>  >     proliferation.
>
> I don't quite understand what do you mean by "unwind cursor abstraction".  May
> you give further explanation?
I'm referring to the AbstractUnwindCursor class in UnwindCursor.hpp. This makes 
a nice platform agnostic interface for these kinds of operations. Also see 
UnwindLevel1.c.
>
> I wrote those static inline function simply because I wish to reuse the code
> with _Unwind_GetGR()/_Unwind_SetGR().  It seems that the header from clang did
> the same thing.
Oh... never mind, I see what you did now.
>
>  > I'm being pedantic here: you say they compile & run, but what's the pass rate?
>
> I have tried every test cases in libcxxabi/test, and all of them are passing
> except one case in test_demangle.cpp.  That case assumes that long double has
> 80-bit, which is not true for ARM.  Thus, I have changed it in the patch.
Ok, excellent. That one was failing for me with [1], and I hadn't looked into it 
yet.
>
> I haven't tried the test case from libc++ yet, though I am planning to do so.
>
> Cheers,
> Logan

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded