Hi Dana, Thanks for your reply. After checking the specification again, I found that it is unnecessary to provide _Unwind_GetLangaugeSpecificDataArea() and _Unwind_GetRegionStart() so you are correct. It seems that we can change the usage in cxa_personality.cpp as well.
Sincerely, Logan On Fri, May 30, 2014 at 7:52 PM, Dana Jansens <[email protected]> wrote: > 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
