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

[Dana Jansens]

On Fri, May 30, 2014 at 1:39 PM, Logan Chien <tzuhsiang.chien at gmail.com>
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 <
> 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/0629c184/attachment.html>