discuss-gnustep
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]