On Jun 3, 2014, at 4:45 PM, Dana Jansens <[email protected]> wrote: > On Wed, Jun 4, 2014 at 1:36 AM, Jonathan Roelofs <[email protected]> > wrote: > > > On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote: > On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <[email protected] > <mailto:[email protected]>> wrote: > > On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <[email protected] > <mailto:[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. > 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. Yes, there has been talk of moving the unwinder to compiler-rt.
> > In our repo we've been mostly using LIBCXX_ARM_EHABI, the _LIBUNWIND_SUPPORT > macro was pretty redundant and rarely used by us, we just ended up with both > somehow. > > At this point we're pretty sure we are unable to nicely support the libunwind > API nicely while sharing the exising UnwindLevel1 implementation with dwarf > systems, since unw_step() is required to actually unwind the stack by the > libunwind API but on ARM the unwind is done by the personality function which > gets called from unwind_phase1, rather than by the unw_step(). > > This kind of mismatch makes it impossible to both share the unwind_level1 > implementation with non-ARMEHABI, and also support libunwind. What we're > planning to do for android is to not export any of the libunwind symbols and > share code in UnwindLevel1 for now. What this means is that the libunwind API > is somewhat just in the way for us if we're not implementing it (and it's not > supposed to be exported by libc++abi anyhow). > > A bit longer-term out we're considering splitting the ARM EHABI code off from > the libunwind and friends code since it makes a number of things much more > awkward for the EhABI spec (step for example, also floating point support. > Antoine pointed out this in an email that has not gotten through moderation > to the list yet. > > All in all, we don't see the value in supporting the libunwind API, and would > prefer to just support the ARM EHABI api (ie _Unwind_Foo), so just using the > LIBCXX_ARM_EHABI makes sense to me. Please let me know what you think here. The setjump-longjump is similar to this. It does not use the lower level libunwind APIs and it has its own phase1/phase2 unwinding code separate from the Itanium style. So, it makes sense to me for the ARM EHABI implementation to be in its own Unwind-ehabi.c file and do not use libunwind under it. This was part of why I thought of EHABI as being a different unwinder than the zero-cost unwinder in terms of _LIBUNWIND_BUILD_blah. -Nick > > > Jon > > Thanks for the quick feedback. > > -Albert > > > -Nick > > > On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs > <[email protected] <mailto:[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]> > <mailto:[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 > > > <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] <mailto:[email protected]> > CodeSourcery / Mentor Embedded > _________________________________________________ > cfe-commits mailing list > [email protected] <mailto:[email protected]> > http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits > <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits> > > > > > > -- > Jon Roelofs > [email protected] > CodeSourcery / Mentor Embedded >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
