J.T. Conklin | 2 Nov 04:53 2007

libpthread and static constructor order

The pthread library's initialization function, pthread_init(), must be
called before any other pthread functions are called.  This is done by
using gcc's __constructor__ function attribute.  While this ensures it
will be called before main(), it's not enough if other static ctors
call pthread functions.

I'm running into this problem now with ACE / TAO, which has static
ctors which end up using pthread's thread specific storage.  If the
ACE / TAO ctors are executed before the libpthread ctor, bad things
happen.  If the libpthread ctor is executed before the ACE / TAO
ctors, everything works fine.  It's not clear to me what is needed to
make the libpthread ctors run first. I've been able to tweak the link
order by explicitly linking with -lpthread, but this is rather fragile.

Is there any way to ensure libpthread's ctors will be run before all
others?  ld.elf_so doesn't appear to grok the DF_1_INITFIRST flag
added by ld's -z initfirst option, and g++'s __init__priority__
function attribute doesn't work across shared libraries.

Without a reliable way to ensure libpthread's initialization is run
before all other static constructors, I think it needs to be changed
so that pthread_init() returns if it's already been initialized, and
something like:

   if (!__isthreaded) {
       pthread_init();
   }

be added to the beginning of some (all?, most?) of the pthread calls.
Are there any other options?
(Continue reading)

der Mouse | 2 Nov 06:25 2007
Picon

Re: libpthread and static constructor order

> Is there any way to ensure libpthread's ctors will be run before all
> others?

I don't know, but I'm quite sure this, even if possible, isn't the
right fix.  If nothing else, it doesn't scale; consider what happens
when another library, with a similar issue, also wants its init routine
called "before all others".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Joerg Sonnenberger | 2 Nov 11:25 2007
Picon

Re: libpthread and static constructor order

On Thu, Nov 01, 2007 at 08:53:53PM -0700, J.T. Conklin wrote:
> I'm running into this problem now with ACE / TAO, which has static
> ctors which end up using pthread's thread specific storage.

In that case the library has to explicitly link against libpthread. ELF
constructors are run in dependency order and if you can build the
library with -z defs, you should be on the save side.

Joerg

J.T. Conklin | 2 Nov 14:57 2007

Re: libpthread and static constructor order

> On Thu, Nov 01, 2007 at 08:53:53PM -0700, J.T. Conklin wrote:
>> I'm running into this problem now with ACE / TAO, which has static
>> ctors which end up using pthread's thread specific storage.
>
> In that case the library has to explicitly link against libpthread. ELF
> constructors are run in dependency order and if you can build the
> library with -z defs, you should be on the save side.

Hmm... This is something I tried yesterday without much success.

The ACE / TAO shared libraries were built with GNU libtool, and I
discovered that libtool links the shared libraries with -nostdlib,
even with -pthread the libpthread dependency was not recorded.  I
changed it to use -nostartfiles instead, which appeared to work
(libpthread was shown before libACE, etc. when doing a "ldd" on both
the shared libraries and executables); but the libpthread ctor was
still called after some of the TAO ctors that used threads.

I'll look into this approach further know that I know that this
"should" work rather than something that "might" work.

    --jtc

--

-- 
J.T. Conklin

Joerg Sonnenberger | 2 Nov 15:01 2007
Picon

Re: libpthread and static constructor order

On Fri, Nov 02, 2007 at 06:57:56AM -0700, J.T. Conklin wrote:
> > On Thu, Nov 01, 2007 at 08:53:53PM -0700, J.T. Conklin wrote:
> >> I'm running into this problem now with ACE / TAO, which has static
> >> ctors which end up using pthread's thread specific storage.
> >
> > In that case the library has to explicitly link against libpthread. ELF
> > constructors are run in dependency order and if you can build the
> > library with -z defs, you should be on the save side.
> 
> Hmm... This is something I tried yesterday without much success.

Note that what I said above is how it *should* behave. From reading
ld.elf_so I am not sure whether it is actually doing that. Can you check
in which order the DT_NEEDED entries are in the binary? I think the part
about resorting the order list is not done at all...

Joerg

Thor Lancelot Simon | 2 Nov 17:40 2007

Re: libpthread and static constructor order

On Fri, Nov 02, 2007 at 06:57:56AM -0700, J.T. Conklin wrote:
> 
> The ACE / TAO shared libraries were built with GNU libtool, and I
> discovered that libtool links the shared libraries with -nostdlib,
> even with -pthread the libpthread dependency was not recorded.

This is a bug in libfool.  If it is building libraries that depend on
other libraries, it must explicitly link in (well, record dependencies
for) all libraries on which the library it's building depends, and not
assume some other library linked into the unlucky executable that links
the libfool- generated library will *just happen* to properly record a
dependency on libpthread or libc (or libX11, or...).

Thor

Christos Zoulas | 2 Nov 20:48 2007

Re: libpthread and static constructor order

In article <877il1481a.fsf <at> orac.acorntoolworks.com>,
J.T. Conklin <jtc <at> acorntoolworks.com> wrote:
>The pthread library's initialization function, pthread_init(), must be
>called before any other pthread functions are called.  This is done by
>using gcc's __constructor__ function attribute.  While this ensures it
>will be called before main(), it's not enough if other static ctors
>call pthread functions.
>
>I'm running into this problem now with ACE / TAO, which has static
>ctors which end up using pthread's thread specific storage.  If the
>ACE / TAO ctors are executed before the libpthread ctor, bad things
>happen.  If the libpthread ctor is executed before the ACE / TAO
>ctors, everything works fine.  It's not clear to me what is needed to
>make the libpthread ctors run first. I've been able to tweak the link
>order by explicitly linking with -lpthread, but this is rather fragile.
>
>Is there any way to ensure libpthread's ctors will be run before all
>others?  ld.elf_so doesn't appear to grok the DF_1_INITFIRST flag
>added by ld's -z initfirst option, and g++'s __init__priority__
>function attribute doesn't work across shared libraries.

We don't grok any of the DF_1_ flags I think.

http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p55.html

>Without a reliable way to ensure libpthread's initialization is run
>before all other static constructors, I think it needs to be changed
>so that pthread_init() returns if it's already been initialized, and
>something like:
>
(Continue reading)

Brian A. Seklecki | 3 Nov 02:30 2007

L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42 (fwd)


For BIND/named(8).

Probably needs to be brought into all supported branches.

~BAS

---------- Forwarded message ----------
Date: Sat, 03 Nov 2007 08:37:24 +1100
From: Mark Andrews <Mark_Andrews <at> isc.org>
Reply-To: bind-users <at> isc.org
To: bind-announce <at> isc.org
Subject: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42

 	If you already have a root hints zone defined in named.conf
 	you need to update the address in the file it loads from.

 	The easiest way to create a new file is to run dig, check
 	the contents of the file it generates then move the file
 	into place.

 		dig ns .  <at> a.root-servers.net > newfile

 	If you don't have any root zone defined they you will be
 	using the built-in hints.  In this case you should create
 	a root hints zone if you don't have a root zone already
 	defined and you are using class IN (the default class).

 		dig ns .  <at> a.root-servers.net > root-hints

(Continue reading)

Matthias Drochner | 3 Nov 17:54 2007
Picon
Picon

install the tzdata "zone.tab" file?


Hi -
some 3rd-party software wants the zone.tab file, to print the
time zone locations on a map or whatever.
(A particular bad example is "evolution" which segfaults without
notice if it is not found.)
Most platforms supported by such software appear to have
that file installed.
NetBSD does not. Should it?
I'm preparing a pkg which does nothing else than to install
a copy of zone.tab. A "builtin.mk" file could be added later
so that it doesn't get installed unnecessarily.

best regards
Matthias

-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------

(Continue reading)

J.T. Conklin | 3 Nov 18:33 2007

Re: libpthread and static constructor order

Joerg Sonnenberger <joerg <at> britannica.bec.de> writes:
> On Fri, Nov 02, 2007 at 06:57:56AM -0700, J.T. Conklin wrote:
>> > On Thu, Nov 01, 2007 at 08:53:53PM -0700, J.T. Conklin wrote:
>> >> I'm running into this problem now with ACE / TAO, which has static
>> >> ctors which end up using pthread's thread specific storage.
>> >
>> > In that case the library has to explicitly link against libpthread. ELF
>> > constructors are run in dependency order and if you can build the
>> > library with -z defs, you should be on the save side.
>> 
>> Hmm... This is something I tried yesterday without much success.
>
> Note that what I said above is how it *should* behave. From reading
> ld.elf_so I am not sure whether it is actually doing that. Can you check
> in which order the DT_NEEDED entries are in the binary? I think the part
> about resorting the order list is not done at all...

Since ACE / TAO are huge, I wrote a small unit test program to verify
NetBSD's behavior (see the enclosed shar file). 

To simplify things, I used gcc's __constructor__ attribute instead of
C++.  There are two shared libraries, libfoo and libbar.  libfoo has a
constructor that writes "foo\n" to standard error; while libbar's ctor 
writes "bar\n".  libfoo has no dependencies, while libbar depends on 
libfoo. 

I've linked a "null" main() program with these shared libraries.  For
"foobar", I've linked with -lfoo -lbar; for "barfoo", I've linked with
-lbar -lfoo.  

(Continue reading)


Gmane