[PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp
Nico Weber
thakis at chromium.org
Wed Jun 4 14:34:17 PDT 2014
Is this new patch fine for now? (Everything else depends on it.)
On Wed, Jun 4, 2014 at 3:27 AM, Dana Jansens <danakj at google.com> wrote:
> Here's an updated patch that uses LIBCXX_API_EHABI. Since this is in
> AddressSpace.hpp which is part of the "libunwind" layer, I've duplicated
> the #define for this from the unwind.h which is part of the "_Unwind" layer
> to avoid including the unwind.h header which doesn't belong in
> AddressSpace.hpp.
>
>
> On Wed, Jun 4, 2014 at 2:29 AM, Dana Jansens <danakj at google.com> wrote:
>
>> 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
>>>
>>
>>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140604/5651e1e4/attachment.html>
More information about the cfe-commits
mailing list