From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 14:50:51 2003 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 F406B37B401 for ; Thu, 19 Jun 2003 14:50:50 -0700 (PDT) Received: from sccrmhc12.attbi.com (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F4E43F93 for ; Thu, 19 Jun 2003 14:50:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc12) with ESMTP id <20030619215048012004um5le>; Thu, 19 Jun 2003 21:50:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA49892; Thu, 19 Jun 2003 14:50:46 -0700 (PDT) Date: Thu, 19 Jun 2003 14:50:45 -0700 (PDT) From: Julian Elischer To: Marcel Moolenaar In-Reply-To: <20030619202013.GA833@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org Subject: Re: Implementing TLS: step 1 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: Thu, 19 Jun 2003 21:50:51 -0000 On Thu, 19 Jun 2003, Marcel Moolenaar wrote: Note: The following applies to ia32, but similar comments woudl apply to other achitectures. One thing to bear in mind is that if you push libthr support for TLS to the absolute maximum you will generate code that is not binary compatible with KSE (when it gets to ia64). Libthr has the advantage that the register used for identifying the current thread can be set DIRECTLY at the thread control block, where libkse will (probably) require a single indirection. (by which I mean that the register will point to the control structure for the Virtual CPU that is running (KSE) and that in turn will have a pointer to the thread that is currently running. So to keep binray compatibility we would need to not push the libthr optimisations to the absolute ends beyond what can be achieved with libkse (unless the loader code relaxer can be set up to use different relaxations depending on which thread library is linked in. (there is SOME precedence for this)). Libc_r can be modified to set the thread pointer register as needed, but it might slow it down. (I was just looking at the ia-32 docs..it's not as bad as I thought to write a segment register so it is feasible to change the segment register in libc_r purely to supplrt TLS). (in a code compatible manner.) One possible optimisation in libkse would be to place a pointer to the TLS object table in the Virtual CPU structure (KSE mailbox) whenever a new thread was scheduled on that KSE/VCPU. This would allow teh generation of code that bypassed the redirection via teh thread structure, at the expence of the extra MOV in the context switch. This would bring it closer to the order of optimisation achievable with 1:1, though the code used for relaxation may or may not be the same. We just need to decide if the cost is worth it.. > Ok, > > Step 1: static TLS in libthr. > > I have gcc33 installed and looked at the access sequences for TLS > on both i386 and ia64. Then I looked at libthr to see what was > needed and the first and obvious orbservation is that we need a > way to figure out if the binary has a TLS template and use it if > it does. If not, we probably need some minimal glue to have the > TLS pointer point to something meaningful. Note again, we don't > have RTLD involved. We're talking staticly linking now. Call me stupid but can you draw a picture of what you mean? (it's worth a thoudsand words you know :-) > > What about the following: > > 1. The kernel already iterates over the program headers and can > pass the address and size of the TLS template to the process > (or RTLD) by means of the auxargs (ie have AT_TLS_ADDR and > AT_TLS_SIZE). If no template exists AT_TLS_* will be zero. > This prevents coding object file dependencies on thread and > allows the RTLD to modify the args even in the event that the > program itself does not have TLS, but libraries in the startup > set do. I need to go out to the car and get my copy of the TLS proposal.... this supports exec-time linking but does it support run-time (i.e after exec has begun) linking? > 2. On thread creation we allocate the TLS space according to the > template (or some MD specific placebo) and put a pointer to it > in struct thread. For static TLS we don't have a means to > lazily allocate the TLS. > 3. The MD _get_curthread() and _set_curthread() will be adjusted > according to the RT spec. if not currently compliant. > > Question: > 1. What's the best way to expose the auxargs to the thread library? > > Alternatives? > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >