On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <[email protected]> wrote:
> 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…) > > (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 < > [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
