Re: Another unwinding problem on ARM

[Mathias Bauer]

Hi David,

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?

It's in the libgcc_s, at the end the call ends up in __gnu_unwind_pr_common.

> > 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...

Yes, that's what I expect to see also. What makes me wonder is what PR 
actually is called in the case where something goes wrong. As long as 
the C personality routine is called, everything seems to be OK, but at 
the first time where an EHT entry points to another PR, there is a problem.

All EHT entries except this one used the compact format with an index 
pointing to a standard PR. The one where things go haywire does not use 
the compact format, and the UCB_PR_ADDR (ucbp) yields an address in 
libgnustepbase by using the offset stored in the EHT entry.

I think the function where it happens is the main method of NSThread 
that has an [NSException raise:...] statement. So whatever code in 
libgnustepbase is jumped to, shouldn't it call the PR in 
eh_personality.c in libobjc2?

Regards,
Mathias