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 <[email protected]> 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>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
