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

[Logan Chien]

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 <danakj at google.com> wrote:

> 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/20140531/a7e040a4/attachment.html>