Hi David,
Am 14.03.14 02:15, schrieb David Chisnall:
On 14 Mar 2014, at 07:50, Mathias Bauer <[email protected]> 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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
