On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <[email protected]> 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 <[email protected]> > 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 <[email protected] > <mailto:[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> > > > -- > Jon Roelofs > [email protected] > CodeSourcery / Mentor Embedded > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
