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

[Nick Kledzik]

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…)
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?

-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/20140603/a2fbdd86/attachment.html>