From owner-freebsd-threads@FreeBSD.ORG Sat Apr 3 14:07:15 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 A9A6A16A4CE for ; Sat, 3 Apr 2004 14:07:15 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FBC343D55 for ; Sat, 3 Apr 2004 14:07:15 -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 i33M79tf019791; Sat, 3 Apr 2004 17:07:10 -0500 (EST) Date: Sat, 3 Apr 2004 17:07:09 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200404032028.50715.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Julian Elischer Subject: Re: PERFORCE change 50188 for review 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: Sat, 03 Apr 2004 22:07:15 -0000 On Sat, 3 Apr 2004, Doug Rabson wrote: > On Saturday 03 April 2004 19:22, Daniel Eischen wrote: > > On Sat, 3 Apr 2004, Doug Rabson wrote: > > > > > > I was just wandering around the internet looking at the scenery and > > > I ended up here: > > > http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html. > > > > Neat. > > > > > This document describes a new options (which is not supported by > > > the compiler in current right now), -mno-tls-direct-seg-refs. This > > > looks like it will do everything we need for both i386 and amd64, > > > i.e. instead of code like: > > > > > > movl %gs:x@ntpoff, %eax > > > > > > it should generate: > > > > > > movl %gs:0, %eax > > > movl x@ntpoff(%eax), %eax > > > > That's what I thought the SUN ABI was supposed to do, no? > > Perhaps I should go back and read the TLS spec... > > The main difference, (for me anyway) is that the calling convention for > tls_get_addr in the sun abi is a standard stack-based convention. This > leads to bulky code sequences which are hard for the linker to > transform when it realises that it can change a reference from e.g. > global dynamic to local exec. Oh, I was really only thinking that the tls_get_addr function and everything else would be pretty much the same as the GNU convention, except that there would be one extra instruction for __thread references (like you show above). I think this is what we were going on from the start. > > > Although I'm still not quite convinced that we can't do the first > > > version with essentially zero cost for i386 at least. > > > > I think it might get messy trying to manage LDTs. Extra > > locking will be needed when you need to borrow them from > > other threads, and you need to make sure those other threads > > aren't running and aren't scope system. You might as well > > make a system call to continue the thread and let the > > kernel do all the work. > > Probably. If we can arrange to reduce the syscall cost somewhat (e.g. > with sysenter/sysexit instead of int $80), perhaps this still isn't too > much of a problem. I think that most programs should do far fewer > context switches than most other work. But everything else being equal, it's so much easier for the one extra instruction in the TLS reference. -- Dan Eischen