[PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

Dana Jansens danakj at google.com
Tue Jun 3 17:29:02 PDT 2014


On Wed, Jun 4, 2014 at 2:09 AM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Jun 3, 2014, at 4:58 PM, Dana Jansens <danakj at google.com> wrote:
>
>
>> The setjump-longjump is similar to this.  It does not use the lower level
>> libunwind APIs and it has its own phase1/phase2 unwinding code separate
>> from the Itanium style.  So, it makes sense to me for the ARM EHABI
>>  implementation to be in its own Unwind-ehabi.c file and do not use
>> libunwind under it.  This was part of why I thought of EHABI as being a
>> different unwinder than the zero-cost unwinder in terms of
>> _LIBUNWIND_BUILD_blah.
>>
>
> We discussed making a change like that, but we're more concerned with
> upstreaming first right now, rather than keeping this all on a private
> repo. Since the way we developed this was sharing code with the itanium
> implementation as much as possible, are you okay with upstreaming it in
> this fashion and then looking at moving it away in the future?
>
>
> Can you be more specific about what you mean by “in this fashion” and
> “moving it away in the future”.
>

Sure! What we have in our repo[1] is an implementation of ARM EHABI on top
of the Itanium APIs. Initially we felt that made a lot of sense, though
more recently we've started thinking about doing something different to fit
the ARM EHABI requirements better. So, currently we are sharing code in
unwind_level1, and AddressSpace and so on, as much as possible. This also
helps keep our diffs smaller, I think.

In the future (maybe 6 months out) we could consider moving the
implementation away from sharing code with itanium with #ifdefs, and moving
to something more separate like SJLJ. But this isn't something we can
realistically commit to doing right now, so it would make upstreaming a lot
more difficult.

What we have is a functioning implementation that passes the tests, so I
think it's not unreasonable. Concretely, this means using #if
LIBCXX_ARM_EHABI throughout each of the three cxxabi, Unwind, and libunwind
layers.

[1]
https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#commit_comments_bucket


>
> -Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140604/cc35b3b6/attachment.html>


More information about the cfe-commits mailing list