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

[Albert Wong (王重傑)]

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

> On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <ajwong at google.com> wrote:
>
> I'm slightly confused at the semantics of the defines.  In my head, "zero
> cost" versus SJLJ are one dimension. Then within ZeroCost, there's the
> Itanium ABI (with DWARF encoding) and the Arm EABI (with EHABI encoding).
>
> Thus, I would have expected __arm__ to be both "zero cost" as well as
> EHABI.
>
> Is my understanding incorrect? (It very well may be…)
>
> (crap...that was supposed to say "it very well may NOT be"....I meant to
express lack of confidence...not sound like a jerk. :(  Sorry about that. )


> Ok.  At an abstract level ARM EHABI is “zero cost”.  But looking at how
> unwind.h has been conditionalized, the EHABI stuff is under
> LIBCXXABI_ARM_EHABI and is almost completely disjoint with the Itanium
> APIs.
>
> You guys are the experts on ARM EHABI.  If you model it is a variant on
> the Itanium zero-cost API, then we can go down the path where
> _LIBUNWIND_BUILD_ZERO_COST_APIS is true.
>
> It would be nice to unify the LIBCXXABI_ARM_EHABI in the header with this
> config.h settings.  Perhaps get rid of
> _LIBUNWIND_SUPPORT_ARM_EHABI_UNWIND and just use LIBCXXABI_ARM_EHABI?
>

I agree with the observation that the Itanium APIs are nearly disjoint.
 Unifying on LIBCXXABI_ARM_EHABI sounds like a pretty good idea. I think
Dana is running with it.

Thanks for the quick feedback.

-Albert


>
> -Nick
>
>
> On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs <
> jonathan at codesourcery.com> wrote:
>
>> Nick,
>>
>> This combines with Logan's work, and implements the libunwind bits that
>> Logan's patch relied on libgcc_s for, in order to get rid of that
>> dependency.
>>
>> Jon
>>
>>
>> On 6/3/14, 3:47 PM, Nick Kledzik wrote:
>>
>>> Dana,
>>>
>>> Is this a separate implementation of ARM EHABI than what Logan proposed
>>> 4/13/2014?  Or is this this same, but broken into steps?
>>>
>>>
>>>
>>>  +  }
>>>> +  #define _LIBUNWIND_BUILD_ZERO_COST_APIS (__i386__ || __x86_64__ ||
>>>> __arm64__ || __arm__)
>>>> +  #define _LIBUNWIND_BUILD_SJLJ_APIS      0
>>>> +  #define _LIBUNWIND_SUPPORT_FRAME_APIS   (__i386__ || __x86_64__)
>>>> +  #define _LIBUNWIND_EXPORT               __attribute__((visibility("
>>>> default")))
>>>> +  #define _LIBUNWIND_HIDDEN               __attribute__((visibility("
>>>> hidden")))
>>>> +  #define _LIBUNWIND_LOG(msg, ...) fprintf(stderr, "libuwind: " msg,
>>>> __VA_ARGS__)
>>>> +  #define _LIBUNWIND_ABORT(msg) assert_rtn(__func__, __FILE__,
>>>> __LINE__, msg)
>>>> +
>>>> +  #define _LIBUNWIND_SUPPORT_COMPACT_UNWIND   0
>>>> +  #define _LIBUNWIND_SUPPORT_DWARF_UNWIND     0
>>>> +  #define _LIBUNWIND_SUPPORT_DWARF_INDEX      0
>>>> +  #define _LIBUNWIND_SUPPORT_ARM_EHABI_UNWIND 1
>>>>  #endif
>>>>
>>> There will be three unwinding models: zero-cost, sj-lj, and EHABI.  So
>>> there
>>> should be three mutually exclusive build settings:
>>>    _LIBUNWIND_BUILD_ZERO_COST_APIS
>>>    _LIBUNWIND_BUILD_SJLJ_APIS
>>>    _LIBUNWIND_BUILD_ARM_EHABI_APIS
>>>
>>> The SUPPORT_{COMPACT_UNWIND,DWARF_UNWIND,DWARF_INDEX} were intended as
>>> ways that
>>> zero-cost unwind information could be encoded.
>>>
>>> The patch above turns on both _LIBUNWIND_BUILD_ZERO_COST_APIS for all
>>> architectures, which is wrong.  It also leaves
>>> _LIBUNWIND_BUILD_ZERO_COST_APIS
>>> true for __arm__ which is probably wrong too.
>>>
>>> -Nick
>>>
>>>
>>> On Jun 2, 2014, at 5:48 AM, Dana Jansens <danakj at google.com
>>> <mailto:danakj at google.com>> wrote:
>>>
>>>> Hi Nick,
>>>>
>>>> Can you please take a look at this patch? With this, we define an
>>>> UnwindInfoSections for ARM EHABI and are able to populate it.
>>>>
>>>> We'll start making use of this in future patches, as Albert laid out
>>>> here:
>>>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-
>>>> Mon-20140526/106670.html
>>>>
>>>> This patch builds and passes tests on Mac.
>>>>
>>>> Thanks,
>>>> Dana
>>>> <ehabi_address_space.diff>
>>>>
>>>
>>>
>> --
>> Jon Roelofs
>> jonathan at codesourcery.com
>> CodeSourcery / Mentor Embedded
>> _______________________________________________
>> 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/31330077/attachment.html>