From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 00:17:53 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 9193C16A4E1 for ; Wed, 25 Feb 2004 00:17:53 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3716B43D1F for ; Wed, 25 Feb 2004 00:17:51 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004022508175001200euunse>; Wed, 25 Feb 2004 08:17:50 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA86421 for ; Wed, 25 Feb 2004 00:17:49 -0800 (PST) Date: Wed, 25 Feb 2004 00:17:47 -0800 (PST) From: Julian Elischer To: FreeBSD current users In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: TLS, Thread Local Storage.. 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, 25 Feb 2004 08:17:53 -0000 On Tue, 24 Feb 2004, Julian Elischer wrote: > > Now that the real threading libraries are in more common usage we need > to tackle TLS. The TLS spec is NOT part of posix, but people are > starting to write software that depends on it (e.g. nvidia) > and that is the real definition of our requirements. > > The definative doc is at: > http://people.redhat.com/drepper/tls.pdf > > We can handle the kernel side pretty much already > (We've had our eye on this for a while) > but it's the tools, linker etc that are going to be the problems.. > The library parts are "understood". > > This is basically a call to find out "who is interested?" > > Some people have already indicated some interest but don't let that stop > them from piping up again now.. > (people often are interested in something but time constraints > etc. change and...) Who can tell me how well our linker understands what gcc puts out when given a __thread directive.. for example, __thread int a= 3; extern __thread int e; int c; int d = 2; void asd(int a, int b, int c, int d, int e){} main() { int b; asd(a,b,c,d,e); } generates: .file "a.c" .globl a .section .tdata,"awT",@progbits .p2align 2 .type a, @object .size a, 4 a: .long 3 .globl d .data .p2align 2 .type d, @object .size d, 4 d: .long 2 .text .p2align 2,,3 .globl asd .type asd, @function asd: pushl %ebp movl %esp, %ebp leave ret .size asd, .-asd .p2align 2,,3 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp movl %gs:0, %eax subl $12, %esp movl e@INDNTPOFF, %edx pushl (%edx,%eax) pushl d pushl c pushl %ecx pushl a@NTPOFF(%eax) call asd addl $32, %esp leave ret .size main, .-main .comm c,4,4 .ident "GCC: (GNU) 3.3.3 [FreeBSD] 20031106" I don't know whether we already have all that is needed from the linker.. I know that @NTPOFF is supported but without going generating test shared libraries it's hard to see if @INDNTPOFF is. The BIG question is "who knows enough about the dynamic linker to be able to make this work for dynamic libraries..?" I gather that our dynamic linker is not the one that linux uses and is specific to us. (Am I wrong?) WHat is the current state of all these tools. We need to also have code to create new tdata and tdss segments for new threads. I guess that's up to the thread people using support code from the dynamic and static linkers. > > > > _______________________________________________ > 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" >