From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 16:45:29 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 20CA516A4CE for ; Tue, 23 Mar 2004 16:45:29 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id D15EC43D2F for ; Tue, 23 Mar 2004 16:45:28 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004032400452601600ng20fe>; Wed, 24 Mar 2004 00:45:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA53146; Tue, 23 Mar 2004 16:47:49 -0800 (PST) Date: Tue, 23 Mar 2004 16:47:47 -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:45:29 -0000 On Tue, 23 Mar 2004, Julian Elischer wrote: > > > 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. I might add that after doing the work for M:N and N:N the code for 1:N may just "fall out" in which case we might look at doing 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. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >