[PATCH] libc++abi: Don't push the unwind_exception to r12 in _gxx_personality_v0.

[Logan Chien]

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 <jonathan at codesourcery.com
> wrote:

>
>
> On 5/29/14, 6:53 PM, Dana Jansens wrote:
>
>> On Thu, May 29, 2014 at 8:27 PM, Jonathan Roelofs <
>> jonathan at codesourcery.com
>> <mailto:jonathan at codesourcery.com>> 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
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140530/10ca3a35/attachment.html>