From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 19:56:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0268D16A4CE for ; Tue, 23 Mar 2004 19:56:43 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id C0C3043D31 for ; Tue, 23 Mar 2004 19:56:42 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 58448 invoked by uid 1002); 24 Mar 2004 03:56:42 -0000 Received: from unknown (HELO ?10.4.1.17?) (64.58.1.252) by smtp.mho.net with SMTP; 24 Mar 2004 03:56:42 -0000 Date: Tue, 23 Mar 2004 21:01:11 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Julian Elischer In-Reply-To: Message-ID: <20040323195009.T55727@pooker.samsco.home> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marcel Moolenaar cc: FreeBSD current users Subject: Re: SF Bay area hackfest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2004 03:56:43 -0000 On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > What else? Is there any platform specific work to be done, outside of the > > > toolchain? > > TLS is "kernel invisible" (other than what we have already done to make > %gs point where we need it.) ((or the equivalent in other > architectures) > so there is no kernel work.. > > that leaves: > > the compiler > the linker > the assembler > the dynamic linker > The thread scheduler/library > > Off the top of my head, I believe these are all the players. > > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked module > or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. > > The thread scheduler/library is expected to create new TLS segments > whenever a new thread is created, and the linker is expected to request > the thread library to add a new TLS segment to each exisiting thread > whenever a new module is linked in that specifies TLS. The scheduler > keeps pointers correct so that at any moment the correct TLS data is > referenced when needed. As mentionned above the dynamic linker and the > thread library have to co-operate about this. > > The compiler and assembler are expected to generate appropriate tokens > and table entries for the run-time items to do the above when they need > to. This should all be in place for Linux. This sounds fine. Feel free to expand the task list with more detail like this. > > There are optimisations that can be made.. > for example lazy segment creation.. > > It is permissable to only allocate a TLS segment for a particular > module, for a particular thread when that thread first tries to access > said module's TLS data. > that requires 'booby-trapping' all the relocation points but slows down > the thread that have the segment allocated.. but you can sometimes gain > this back by reduced data spread and cache effects. > Let's get basic functionality woring on x86 and amd64 before we start diverging into optimization strategies. Scott