Re: Another unwinding problem on ARM

[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