[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another unwinding problem on ARM
From: |
David Chisnall |
Subject: |
Re: Another unwinding problem on ARM |
Date: |
Wed, 19 Mar 2014 07:13:27 +0000 |
Applied in r37753, thanks!
David
On 18 Mar 2014, at 17:53, Mathias Bauer <mathias_bauer@gmx.net> wrote:
> Hi,
>
> please review and perhaps apply the attached patch.
>
> Thanks and best regards,
> Mathias
>
> Am 14.03.14 13:56, schrieb Mathias Bauer:
>> Hi,
>>
>> once you find it, the solution quite often is easy. :-)
>>
>> The culprit was that unwind-arm.h in libobjc2 can't cope with unwind
>> states that have been "or-ed" with _US_FORCE_UNWIND.
>>
>> Defining it in this file and replacing
>>
>> switch(state)
>>
>> with
>>
>> switch(state & ~_US_FORCE_UNWIND)
>>
>> helps.
>>
>> Without that, the PR wrapper in this header file always returns
>> _URC_FAILURE. I overlooked that in the first place because I only looked
>> whether internal_objc_personality was called.
>>
>> Now the test case works - at least when run inside gdb. I still have to
>> find out why it core dumps without gdb.
>>
>> Regards,
>> Mathias
>>
>>
>> Am 14.03.14 02:15, schrieb David Chisnall:
>>> On 14 Mar 2014, at 07:50, Mathias Bauer <mathias_bauer@gmx.net> wrote:
>>>
>>>> This time again standard PRs in libgcc are used 4 times, but then a
>>>> different PR is used. This PR does return neither INSTALL_CONTEXT
>>>> nor CONTINUE_UNWIND, thus the unwind function returns to
>>>> pthread_exit, causing the app to abort.
>>>
>>> Do you know what the personality routine that is being invoked is?
>>>
>>>> The PR is taken from the EHT of that frame. The offset points into
>>>> libgnustepbase, the PR of the Objective-C runtime is not called.
>>>> OTOH in the same test case on Linux X86_64 the PR in libobjc2 *is*
>>>> called at this point. Is it possible that there is still something
>>>> funky in the EHT entries of Objective-C code?
>>>
>>> We should be using the C personality routine for frames that don't
>>> have any Objective-C @try blocks or C++ try blocks, but do have
>>> cleanups, so that's not necessarily wrong...
>>>
>>> David
>>>
>>> -- Sent from my IBM 1620
>>>
>>
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> <unwind-arm.diff>_______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
- Re: Another unwinding problem on ARM, (continued)
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/13
- Re: Another unwinding problem on ARM, David Chisnall, 2014/03/13
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/14
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/14
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/14
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/18
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/19
- Re: Another unwinding problem on ARM, David Chisnall, 2014/03/20
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/20
- Re: Another unwinding problem on ARM, Mathias Bauer, 2014/03/18
- Re: Another unwinding problem on ARM,
David Chisnall <=