|
From: | Mathias Bauer |
Subject: | Re: Another unwinding problem on ARM |
Date: | Fri, 14 Mar 2014 13:56:14 +0100 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |