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

[Jonathan Roelofs]

On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote:
> On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <kledzik at apple.com
> <mailto:kledzik at apple.com>> wrote:
>
>     On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <ajwong at google.com
>     <mailto: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.
I would rather this didn't happen.

I think it is important to maintain libunwind and libc++abi as two separate 
projects, and unifying this macro across the two of them is going to make that 
separation even harder to keep.

Jon
>
> Thanks for the quick feedback.
>
> -Albert
>
>
>     -Nick
>
>
>>     On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs
>>     <jonathan at codesourcery.com <mailto: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>
>>             <mailto: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
>>                 <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 <mailto:jonathan at codesourcery.com>
>>         CodeSourcery / Mentor Embedded
>>         _________________________________________________
>>         cfe-commits mailing list
>>         cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>>         http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
>>         <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>>
>>
>
>

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