Subject: Re: bin/37347: ld.elf_so does not execute .init/.fini functions in
To: None <gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,>
From: J.T. Conklin <jtc@acorntoolworks.com>
List: netbsd-bugs
Date: 11/11/2007 17:00:05
The following reply was made to PR bin/37347; it has been noted by GNATS.

From: jtc@acorntoolworks.com (J.T. Conklin)
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/37347: ld.elf_so does not execute .init/.fini functions in
 order
Date: Sun, 11 Nov 2007 08:57:59 -0800

 Andrew Doran <ad@NetBSD.org> writes:
 >  I have tried out the supplied patch and it works for me on -current with
 >  free -> xfree. There is another problem: I see a lot of calls into
 >  libpthread before it is initialized, and those calls are made from within
 >  libc.
 
 >  I think that the setup for libpthread should happen via a
 >  constructor in libc, which solves the problem for me. Below is the
 >  libc bit; in libpthread we just override __libc_thr_init().
 
 libpthread doesn't record libc as a dependency, so even with my ld.so
 patch the initialization order is undefined between the two libraries.
 If this is fixed, libc constructors would deterministically call into
 libpthread before libpthread is initialized.  While deterministically 
 failing is better than intermittently succeeding, it points out that 
 something like Andrew's suggestion to have libc initialize libpthread 
 is needed.
 
     --jtc
 
 -- 
 J.T. Conklin