This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: (glibc-2.0.7) c++ constructors and pthreads
- To: davem@dm.cobaltmicro.com (David S. Miller)
- Subject: Re: (glibc-2.0.7) c++ constructors and pthreads
- From: hjl@lucon.org (H.J. Lu)
- Date: Sun, 18 Oct 1998 11:03:12 -0700 (PDT)
- Cc: libc-hacker@cygnus.com
>
>
> I have a crash case here for a program which has global c++
> constructors and links against linuxthreads, one of the c++
> constructors ends up calling malloc(), and this crashes because the
> pthread constructor has not run yet and malloc() wants to setup it's
> internal locks in the private area of the pthread_initial_thread.
>
> This is deadly on machines such as Sparc which have to do
> INIT_THREAD_SELF to initialize a global register to point to the
> thread information block.
>
> This looks rather nasty and I cannot think of a clean fix to make sure
> pthread's constructor runs early enough in a guarenteed manner.
>
I don't think it is too hard to make sure that the pthread constructor
always runs first. I am thinking something adding
extern void _pthread_initialize ();
#pragma weak _pthread_initialize
if (_pthread_initialize)
_pthread_initialize ();
somewhere and make sure it is called before _init (). Of course, we
have to change pthread_initialize also.
--
H.J. Lu (hjl@gnu.org)