From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 13:49:56 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 9061116A4CE; Tue, 23 Mar 2004 13:49:56 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3699043D1D; Tue, 23 Mar 2004 13:49:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2NLnptf002571; Tue, 23 Mar 2004 16:49:51 -0500 (EST) Date: Tue, 23 Mar 2004 16:49:51 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <20040323140429.L55727@pooker.samsco.home> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marcel Moolenaar cc: Julian Elischer 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: Tue, 23 Mar 2004 21:49:56 -0000 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, ... > Modify dynamic linker for TLS ??? > > What else? Is there any platform specific work to be done, outside of the > toolchain? -- Dan Eischen