This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch] Tweak gthr-posix.h for pthread_create() Interceptors
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Hans Boehm <hans dot boehm at hp dot com>
- Date: Thu, 28 Oct 2004 22:58:47 +0530
- Subject: [Patch] Tweak gthr-posix.h for pthread_create() Interceptors
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=H7Q3EELwL3Xmnu2B82Kui3Ggpds14rBh6mCaACR2mP+lpW8BAPCMLoJedVw38uHJnRqK1fT3LHVNsCyO6mk+sLvy6lEkU4qQpK6mAAuEA3pjM0I1yDq7slfKXfzNWpmnzZfVLFOg0XuvL7dn57/IhwUsnDcb/gJHVzdlUKHZJ+4=
- Reply-to: Ranjit Mathew <rmathew at gmail dot com>
Hi,
The following is a minor tweak to gthr-posix.h to enable
it to work with programs/libraries that intercept pthread_create
(for example garbage collectors, profilers, etc.) in case
of *single-threaded* applications, that is end-user applications
that do not really use pthreads.
Here's the actual problem I ran into that motivated this:
Qprof is an application profiler that is preferred by
some people over oprofile or gprof. The way it works
on Linux is by using LD_PRELOAD to put in its
own interceptor functions, including one for
pthread_create(). Note that it does not intercept
any other pthreads function.
__gthread_active_p() determines if pthreads is
being used on targets supporting weak symbols
by seeing if pthreads_create resolves properly.
So when qprof is used with a single-threaded
C++ program (even the most trivial "Hello World"),
this creates problems which manifests itself
as a Segmentation Fault (more precisely, the
call to pthread_once() fails in __gthread_once(),
which is called by the locale initialisation code).
A possible workaround for the immediate problem
is to explicitly link the application with pthreads,
but that is fraught with uncertain behaviour.
Another is to change qprof to intercept something
else, but that is not robust.
So the following is the simplest way I could
find out of this weird problem. I note that
__gthread_active_ptr is used purely for checking
this bit and is not used anywhere else. I chose
pthread_once() as that is a function that *is*
used by gthreads with pthreads and should
cause less interference with interceptors
libraries.
Tested on i686-pc-linux-gnu.
OK?
Any other ways out of the problem?
Thanks,
Ranjit.
Index: ChangeLog
from Ranjit Mathew <rmathew@hotmail.com>
* gthr-posix.h (__gthread_active_p): Use pthread_once instead of
pthread_create to find if threads are enabled.
Index: gthr-posix.h
===================================================================
--- gthr-posix.h 2004-10-28 20:43:21.000000000 +0530
+++ gthr-posix.h 2004-10-28 20:44:28.000000000 +0530
@@ -106,7 +106,7 @@ static inline int
__gthread_active_p (void)
{
static void *const __gthread_active_ptr
- = __extension__ (void *) &pthread_create;
+ = __extension__ (void *) &pthread_once;
return __gthread_active_ptr != 0;
}