From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 14:05:24 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 A92F637B401 for ; Thu, 19 Jun 2003 14:05:24 -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 B71F843FB1 for ; Thu, 19 Jun 2003 14:05:23 -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 h5JL5NDZ071314; Thu, 19 Jun 2003 14:05:23 -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 h5JL5N17001123; Thu, 19 Jun 2003 14:05:23 -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 h5JL5NuW001122; Thu, 19 Jun 2003 14:05:23 -0700 (PDT) (envelope-from marcel) Date: Thu, 19 Jun 2003 14:05:23 -0700 From: Marcel Moolenaar To: Alexander Kabaev Message-ID: <20030619210523.GA1030@dhcp01.pn.xcllnt.net> References: <20030619202013.GA833@dhcp01.pn.xcllnt.net> <20030619164228.6d2e7dd2.ak03@gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030619164228.6d2e7dd2.ak03@gte.com> User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: Implementing TLS: step 1 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: Thu, 19 Jun 2003 21:05:24 -0000 On Thu, Jun 19, 2003 at 04:42:28PM -0400, Alexander Kabaev wrote: > > > > 1. The kernel already iterates over the program headers and can > > pass the address and size of the TLS template to the process > > (or RTLD) by means of the auxargs (ie have AT_TLS_ADDR and > > AT_TLS_SIZE). If no template exists AT_TLS_* will be zero. > > This prevents coding object file dependencies on thread and > > allows the RTLD to modify the args even in the event that the > > program itself does not have TLS, but libraries in the startup > > set do. > > Any reason why existing AT_PHDR is not enough? I assume that in the dynamic case the rtld will construct the TLS for the initial load set. This is what the threads library should use as the TLS template. Put differently: if the threads library looks at the object file itself, it will correctly obtain the TLS template in static binaries, but will not have the correct template in shared binaries. What is missing are the TLS templates in the shared libraries in the initial load set in that case. > ... For static binaries, startup code will have to parse AT_PHDR and > store TLS attributes in a global variable or call a function defined by > the thread library. If I remember correctly, libpthread people wanted to > have that function anyway. This is possible and removes the dependency on the kernel for passing the info in auxargs. The issue with this is that the startup code may be doing it for nothing (non-threaded binaries), or interfere in getting the right information to the threads library and thus making it rather complex. What about the following: The startup code provides a weak function (__tls_template() or something like that) that is also provided (non-weak) by the rtld. The threads library calls this function to obtain the TLS of the initial load set (which for static binaries boils down to looking up PT_TLS)? The object details are hidden in the startup code and the difference between static and dynamic is handled by binding. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net