Hi all, Sorry for the late reply. I am just feeling sick these days. :-(
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. (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? 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
