From owner-freebsd-threads@FreeBSD.ORG Fri Jun 20 13:43:16 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9773437B401 for ; Fri, 20 Jun 2003 13:43:16 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCEA43FBF for ; Fri, 20 Jun 2003 13:43:15 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5KKhFDZ077892 for ; Fri, 20 Jun 2003 13:43:15 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5KKhER8019187 for ; Fri, 20 Jun 2003 13:43:14 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5KKhExk019186 for threads@FreeBSD.org; Fri, 20 Jun 2003 13:43:14 -0700 (PDT) (envelope-from marcel) Date: Fri, 20 Jun 2003 13:43:14 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org Message-ID: <20030620204314.GA19111@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: TLS: defining the problem space X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 20:43:16 -0000 Gang, After the first round of discussions, it seems beneficial to draw the problem space. As far as I can see it, we have a 3-dimensional problem space: X. complete vs shared executable. Complete means static, but is a term used in certain environments. The advantage of complete in this context is that it allows us to use static to mean something else. The big difference between complete and shared is the presence (or absence) of RTLD. Y. static vs dynamic. This of course refers to the TLS model in use. A process can have both models in use at the same time!, but only if the process belongs to a complete binary (ie: you cannot have the static TLS model in shared executables, but you can have the dynamic TLS model in complete executables. The big difference between static and dynamic is the use of __tls_get_addr() to get the virtual address of a thread local variable (or not). Z. with pthread vs without pthread. This means whether a threads library (libc_r, libthr or libkse) is present and/or in use. The existence of the __thread keyword does not imply or mean that the process will be multi-threaded. This means that we have to deal with TLS access outside the context of RTLD or pthread. The big difference between pthread and without pthread is the ability to actually have multiple threads. Examples of problems we need to solve are: o In a complete executable, without pthread and using dynamic TLS, what defines __tls_get_addr() and how is it defined? o In a complete executable, without pthread and using static TLS, where is the thread pointer initialized? Examples of answers we have, but may need to revise: o In a complete executable, with pthread and using static TLS, the thread pointer is defined by the pthread library. o In a complete executable, with pthread and using dynamic TLS, __tls_get_addr() is defined by the pthread library. The intend of the posting is to come up with all questions and make sure we have them all answered before we do anything else. Note that answers may have tricky consequences, such as: If pthread defines __tls_get_addr() in complete executables and RTLD defines __tls_get_addr() in shared executables, we have duplicate definitions for shared executables, with pthread (using dynamic TLS). Which takes precedence? [answer: RTLD] It probably helps to have a authoritative list of questions and answers. I can probably create a trivial page somewhere where we list it... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net