NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)
Dave,
When I attempt to test syscall cancellation with NPTL threads the interface complains that:
libgcc_s.so.1 must be installed for pthread_cancel to work
I don't have this installed, instead I have libgcc_s.so.2 installed by gcc 4.x during the tls toolchain compile/install.
The code in question is nptl/sysdeps/pthread/unwind-resume.c, which does this:
---
static void
init (void)
{
void *resume, *personality;
void *handle;
handle = __libc_dlopen ("libgcc_s.so.1");
if (handle == NULL
|| (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
|| (personality = __libc_dlsym (handle, "__gcc_personality_v0")) == NULL)
__libc_fatal ("libgcc_s.so.1 must be installed for pthread_cancel to work\n"); libgcc_s_resume = resume; libgcc_s_personality = personality;
}
---
or
---
voidpthread_cancel_init (void)
{
void *resume, *personality, *forcedunwind, *getcfa; void *handle;
if (__builtin_expect (libgcc_s_getcfa != NULL, 1))
return;
handle = __libc_dlopen ("libgcc_s.so.1");if (handle == NULL
|| (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
|| (personality = __libc_dlsym (handle, "__gcc_personality_v0")) == NULL
|| (forcedunwind = __libc_dlsym (handle, "_Unwind_ForcedUnwind"))
== NULL
|| (getcfa = __libc_dlsym (handle, "_Unwind_GetCFA")) == NULL
#ifdef ARCH_CANCEL_INIT
|| ARCH_CANCEL_INIT (handle)
#endif
)
__libc_fatal ("libgcc_s.so.1 must be installed for pthread_cancel to work\n"); libgcc_s_resume = resume;
libgcc_s_personality = personality;
libgcc_s_forcedunwind = forcedunwind;
libgcc_s_getcfa = getcfa;
}
---
It wants to "forward" the local calls for _Unwind_Resume, __gcc_personality_v0, _Unwind_ForcedUnwind and _Unwind_GetCFA to those in ligcc_s.so.1.
The call sequence is like this:
(Enter cancellable syscall)
...__libc_enable_asynccancel
__do_cancel
__pthread_unwind
(Calls _Unwind_GetCFA ...)...
(Do the syscall)
...__libc_disable_asynccancel
...
(Done)
This is called to enable unwinding out of a cancelled syscall. What was the reason for DSO version bump in libgcc_s.so.1?
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 1 line
What was the reason for DSO version bump in libgcc_s.so.1?
It was done to distinguish between libgcc_s's built with sjlj and dwarf2 eh support, respectively. They use incompatible unwind routines and it's not possible to support both exception handling techniques with one library.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 5 lines · John David Anglin
Quoted 1 line
What was the reason for DSO version bump in libgcc_s.so.1?
It was done to distinguish between libgcc_s's built with sjlj and dwarf2 eh support, respectively. They use incompatible unwind routines and it's not possible to support both exception handling techniques with one library.
So libgcc_s.so.1 is for dwarf2?
While libgcc_s.so.2 is for sjlj?
Thus NPTL thread cancellation seems to requires dwarf2 eh support. How do I enable sjlj versus dwarf2 (--enable-dwarf2-exceptions?)
Our build script is here if you want to have a look:
http://cvs.parisc-linux.org/build-tools/build-tls-tools?rev=1.5&view=markup
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux