This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using clone with glibc


Basically, if you want to call libc functions you should do it from a
thread that was set up by libc or libpthread.  i.e., if you make your own
threads with clone, only call libc functions from the initial thread.

The interfaces needed to initialize a thread pointer structure with the
fields libc relies on, even when not using libpthread, are private.  You
can indeed call _dl_allocate_tls, but it is in the GLIBC_PRIVATE symbol
version set to indicate that its calling conventions might change or
disappear in any future libc version.  The only reason it's accessible at
all is because ld.so, libc, and libpthread share this symbol and the way
ELF works that makes it available to you as well.

This is all the case when libc itself uses TLS.  If you build a libc DSO
that does not use TLS itself and do not use libpthread at all, then nothing
will use the thread pointer (%gs segment on x86).  For example, on Fedora
systems the normal glibc installation includes multiple different
libc+libpthread DSO sets built in different ways.  Any NPTL build requires
TLS.  When building glibc with Linuxthreads instead, TLS use can be turned
off, and it is in the Fedora builds.  On Fedora, you can use
LD_ASSUME_KERNEL=2.4.19 in the environment to make sure you don't get the
NPTL build of libc for that program run.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]