From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 16:31:21 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 2C6E337B404 for ; Thu, 19 Jun 2003 16:31:21 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D46843FAF for ; Thu, 19 Jun 2003 16:31:19 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5JNUgDZ072074; Thu, 19 Jun 2003 16:30:42 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5JNUg17001597; Thu, 19 Jun 2003 16:30:42 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5JNUgHX001596; Thu, 19 Jun 2003 16:30:42 -0700 (PDT) (envelope-from marcel) Date: Thu, 19 Jun 2003 16:30:42 -0700 From: Marcel Moolenaar To: Julian Elischer Message-ID: <20030619233042.GD1273@dhcp01.pn.xcllnt.net> References: <20030619223608.GB1273@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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 23:31:21 -0000 On Thu, Jun 19, 2003 at 04:03:30PM -0700, Julian Elischer wrote: > > > The compiler generates access sequences according to the runtime > > specification which in general means that all offsets to the TLS > > are based on some TLS base address. On ia64 the thread pointer > > points to the TLS and serves as the TLS base address. On other > > architectures there may be an indirection. This means that on ia64 > > the lack of TLS still requires us to allocate something for the > > thread pointer to point to. On other architectures this may not be > > the case. > > > > A typical access sequence on i386 is: > > > > 00000000 : > > 0: 55 push %ebp > > 1: 89 e5 mov %esp,%ebp > > 3: 65 a1 00 00 00 00 mov %gs:0x0,%eax > > 9: 8b 80 00 00 00 00 mov 0x0(%eax),%eax > > f: c9 leave > > 10: c3 ret > > The example you show doesn't have any offset into the TLS, > just returning the base address of the dtv, correct? This is an access sequence for static TLS. There's no DTV in that case. > you still need do significant work to get from teh dtv to the address of > the variable. (at least according to Figure 1.) or are you talking about > something else? The access sequence in the dynamic TLS model is more complex (and dog slow due to the call). For the same C code that yields the static TLS access sequence above: 00000000 : 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 53 push %ebx 4: e8 00 00 00 00 call 9 9: 5b pop %ebx a: 81 c3 03 00 00 00 add $0x3,%ebx 10: 8d 04 1d 00 00 00 00 lea 0x0(,%ebx,1),%eax 17: e8 fc ff ff ff call 18 1c: 8b 00 mov (%eax),%eax 1e: 8b 1c 24 mov (%esp,1),%ebx 21: c9 leave 22: c3 ret The DTV fodder is abstracted y the __tls_get_addr() function. Here the relocations are: RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000c R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 00000013 R_386_TLS_GD i 00000018 R_386_PLT32 ___tls_get_addr > that's fine.. I can arrange that at the address specified by %gs:0 > is a pointer to anything that is needed. > What I can't arrange is that %gs:0 IS the address of the TLS. > (well maybe I can.. hmmmm...) On i386, gs:0x0 does not have to point to the TLS. There's no equivelent of gs:0x0 on ia64. > > > > 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? > > > > Yes. The rtld will dynamicly construct the TLS template from the > > images in the ELF files in the startup set and pass this in > > AT_TLS_* by overriding the values (at least that was the idea). > > > > But if you add a nwe library after threads already exist then you need > to add those extra TLS segments to teh existing TLS objects that are > attached to already running threads. The code you show can't do that.. See above. In the static TLS model there's no support for accessing TLS in dynamicly loaded libraries. That's where the dynamic TLS model kicks in. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net