From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 16:34:16 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 6EAD816A4CE; Tue, 23 Mar 2004 16:34:16 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A2B543D41; Tue, 23 Mar 2004 16:34:16 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004032400341401600nca7je>; Wed, 24 Mar 2004 00:34:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA53079; Tue, 23 Mar 2004 16:36:37 -0800 (PST) Date: Tue, 23 Mar 2004 16:36:35 -0800 (PST) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: Marcel Moolenaar 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 00:34:16 -0000 On Tue, 23 Mar 2004, Daniel Eischen wrote: > On Tue, 23 Mar 2004, Scott Long wrote: > > > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > With new binutils we should (*) be able, with minimal more work be able > > > to generate statically linked binaries using TLS. (*) the loader needs > > > to set some values into symbols and the thread scheduler needs code to > > > allocate a segment of 'M' bytes every time it rceates a new thread and > > > set a pointer to it.. (it already allocates some info but it needs to > > > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > > > size. > > > > > > The next step would be to add code to the dynamic linker to be able to > > > allocate TLS segments to modules as it loads them. The TLS spec pretty > > > much outlines what needs to be done.. > > > > > > We NEED to do this.. it is not a "may be nice" item. > > > TLS is becoming standard on many platforms and more and more software > > > is ASSUMING it is present. (e.g. nvidia drivers). > > > > > > > So what david is asking for (and what I've asked for in the past) is a > > list of tasks that need to be done, and and who is going to be responsible > > for each one. This is a very reasonable request, and is one that I'm > > For the KSE bits, we've already said a few times that we're > ready to go but are waiting for a toolchain upgrade that > supports TLS. > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > unfinished TLS support. SO let me start the list, and I'll let you and > > others add to it. If we can't get through this step, then there is > > absolutely no way that we can expect to get this done for 5.3. And for > > the record, I would really, really like to see this done for 5.3. > > I don't quite understand why you need commitments for a toolchain > upgrade. From what I understand, TLS support can't happen without > it, and by deferring the toolchain update you prevent it from > getting done. But I'll play along regardless... > > > Task Owner > > > > Import new GCC Alexander Kavaev > > Import new binutils ??? > > Modify loader (image activator?) > > to understand TLS ??? > > Modify KSE to understand TLS ??? > > Yes, I'm sure I and/or David can support this. > > > Modify THR to understand TLS ??? > > Modify C_R to understand TLS ??? > > Death to C_R, death to C_R, ... I don't think we will support it. > > > Modify dynamic linker for TLS ??? > > > > 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. 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.