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