From owner-freebsd-threads@FreeBSD.ORG Sun Sep 2 08:33:29 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C27D816A419; Sun, 2 Sep 2007 08:33:29 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 2206B13C468; Sun, 2 Sep 2007 08:33:28 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l828XP7W018386; Sun, 2 Sep 2007 09:33:26 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: Jin Guojun In-Reply-To: <46D734A1.2090700@george.lbl.gov> References: <46B245D5.1050606@george.lbl.gov> <20070803090530.GH2738@deviant.kiev.zoral.com.ua> <46D734A1.2090700@george.lbl.gov> Content-Type: text/plain Date: Sun, 02 Sep 2007 09:33:25 +0100 Message-Id: <1188722005.1058.32.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/4128/Sun Sep 2 06:54:56 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: threads@freebsd.org, hackers@freebsd.org Subject: Re: How TLS is used in Kernel thread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 08:33:29 -0000 On Thu, 2007-08-30 at 14:20 -0700, Jin Guojun wrote: > By looking through _pthread_create() code and find it uses a magic > cookie -- TLS -- created > by rtld_allocate_tls(), and passed into kernel by sysarch() via > _tcb_set() / _kcb_set(). > > The information seems to be set by rtld (ld-elf.so.1) in digest_phdr() > under tag PT_TLS. > But it is very magic for where the TLS object is created and how it is > passed to digest_phdr(). > > The whole object passed into kernel (as sd.gsbase) looks like this: > > TCB: ______________________________ > | TLS | TCB | > |______________|_______________| > > Can someone give some basic exaplain on following questions? > > 1) What TLS stand for? Its used to implement Thread-Local-Storage variables. These are global variables declared with the '__thread' keyword. Each variable declared in this way has a per-thread value (i.e. each thread has a private copy of the variable). > 2) Where TLS object is created? (below is the tls assigned, but I couls > not find where ph is from) > case PT_TLS: > obj->tlsindex = 1; > obj->tlssize = ph->p_memsz; > obj->tlsalign = ph->p_align; > obj->tlsinitsize = ph->p_filesz; > obj->tlsinit = (void*) ph->p_vaddr; Most of the work of dealing with TLS happens in the runtime linker /libexec/ld-elf.so.1. The runtime linker calculates the TLS size based on the TLS usage of all loaded libraries. The thread library uses an internal interface to rtld (_rtld_allocate_tls and _rtld_free_tls) during thread creation and destruction to allocate and free the TLS blocks. As you have seen, the memory allocated also includes the thread-library's control structures (which includes the saved register set etc.). Static programs have a slightly simpler mechanism (simpler because there is only the main program and no dynamic libraries). This is handled in src/lib/libc/gen/tls.c. > > 3) Where in kernel the TLS is used for thread operation? The kernel doesn't use this information at all. It simply provides support for the thread libraries needs. From owner-freebsd-threads@FreeBSD.ORG Mon Sep 3 11:08:42 2007 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73E416A420 for ; Mon, 3 Sep 2007 11:08:42 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3CD13C45B for ; Mon, 3 Sep 2007 11:08:42 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l83B8g9s079228 for ; Mon, 3 Sep 2007 11:08:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l83B8fJM079224 for freebsd-threads@FreeBSD.org; Mon, 3 Sep 2007 11:08:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2007 11:08:41 GMT Message-Id: <200709031108.l83B8fJM079224@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 11:08:42 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/113666 threads misc/shared-mime-info doesn't install, can't find thre 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/114982 threads threads sends error messages to stdout o threa/115211 threads pthread_atfork misbehaves in initial thread 12 problems total.