From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 13:57:57 2004 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 8908C16A4CE for ; Mon, 29 Mar 2004 13:57:57 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E17C543D48 for ; Mon, 29 Mar 2004 13:57:56 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2TLvDYE012232; Mon, 29 Mar 2004 22:57:13 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Julian Elischer Date: Mon, 29 Mar 2004 22:57:13 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403292257.13481.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-threads@freebsd.org Subject: Re: Thread Local Storage 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: Mon, 29 Mar 2004 21:57:57 -0000 On Monday 29 March 2004 22:50, Julian Elischer wrote: > On Mon, 29 Mar 2004, Doug Rabson wrote: > > How do you do that without an expensive syscall? > > Each cpu has a GDT entry pointing to a slightly different location > and the kernel and the UTS co-operate as to making the contents of > that location keep track of the thread currently running. The kernel > always makes sure that %gs points to the correct place when it goes > back to userland and teh contents of that location is saved whenever > a thread sleeps and is restored whenever it wakes up again. > > it can even be in kernel memory space as long as teh segment > is defined as r/w to the user and the segment size is limitted to > just that region it is allowed to read from. > This actualy gives us a 'per thread' pointer rather than a per-kse > pointer which might allow us to go to the GNU version of TLS but we > haven't worked out the details.. > David and peter have both looked at this but we haven't actually > tried to do it yet.. Yes, I understand about the per-cpu GDT thing. I've been reading linux kernel code and glibc all afternoon and my brain is melting :-). It would work great for libthr. For the GNU TLS ABI, the %gs segment can't be in kernel space because of the negative offset thing which is generated by the local exec TLS model. That idiom requires the %gs segment to have a 4G limit so that the negative addresses can wrap round properly. If it wasn't for that single 'optimisation', we could just go with the GNU model right now. My question is, given that we are switching threads in userland, how can we get the right contents for the GDT without a syscall?