On Fri, May 30, 2014 at 1:39 PM, Logan Chien <[email protected]> wrote:
> Hi all, > > Sorry for the late reply. I am just feeling sick these days. :-( > No problem, thanks for the reply :) > It's fine with me to guard the r12 code with #if > defined(LIBCXXABI_WITH_LIBGCC) or something like that, so that the code > base can work with and without libgcc. > > However, I have several questions on this patch. > > (1) I am carious on the reason why does changing r12 will break libc++abi > test (with your unwinder)? IIRC, r12 is a scratch pointer which won't be > saved between function calls. Thus, most function will not (and should > not) assume that r12 won't be clobbered between function calls. > It hsa no effect on our tests, so it's not breaking anything. It just appeared completely unneeded given our implementation of the ARM EHABI unwinder. > > (2) I am afraid that we are not on the correct path. Shouldn't the > unwinder implement _Unwind_GetLanaguageSpecificData() and > _Unwind_GetRegionStart() so that the other language-semantic library (say > Obj-C) can implement their ABI library on top of these functions? > AFAIK these methods are not part of the ARM EHABI, because these are passed to the personality function through the pr_cache. So, while we should implement them in the unwinder in general, we don't need to implement them for ARM EHABI. Hopefully we're not missing something here? Cheers, Dana > Thanks. > > Sincerely, > Logan > > > On Fri, May 30, 2014 at 9:51 AM, Jonathan Roelofs < > [email protected]> wrote: > >> >> >> On 5/29/14, 6:53 PM, Dana Jansens wrote: >> >>> On Thu, May 29, 2014 at 8:27 PM, Jonathan Roelofs < >>> [email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 5/28/14, 9:08 AM, Dana Jansens wrote: >>> >>> - // Copy the address of _Unwind_Control_Block to r12 so that >>> _Unwind___GetLangauageSpecificData() >>> >>> - // and _Unwind_GetRegionStart() can return correct address. >>> - _Unwind_SetGR(context, REG_UCB, >>> reinterpret_cast<uint32_t>(__unwind_exception)); >>> >>> >>> >>> Hey! Thanks for the pointers. >>> >>> libgcc does in fact need us to pass the UCB in r12. See: >>> gcc-trunk-4.8/libgcc/arm/pr-__support.c. >>> >>> >>> >>> It looks like we only need to call these methods on !ARM EHABI from our >>> own >>> libc++abi personality function. So I'm going to move them into that #if, >>> along >>> with the register setting, and avoided calling either method on ARM >>> EHABI. >>> >>> >>> We should probably keep this, but put it under LIBCXXABI_USE_GLIBC >>> for when >>> using libgcc's unwinder with libc++abi, as our unwinder >>> implementation >>> doesn't do it that way. >>> >>> >>> I think our local LIBCXXABI_USE_GLIBC is a mis-nomer and it's going to >>> go away. >>> We probably want to pull our unwind library out of libc++abi so that we >>> can drop >>> in GCC's if desired. It seems like our libc++abi shouldn't necessarily >>> know what >>> unwinder it will be using at compile time, but should just work with >>> whichever >>> gets used? >>> >> Good point. Given that, maybe we ought to keep it in there. >> >> >>> However, for now we aren't passing the needed data to the personality >>> function >>> on EHABI yet upstream so we need to keep calling these _Unwind methods >>> there >>> still also. So I'm going to hold off on this patch until we upstream >>> some other >>> dependent pieces for this to make more sense. >>> >> SGTM >> >>> >>> Thanks! >>> - Dana >>> >> >> -- >> 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
