Date: Tue, 23 Mar 2004 21:01:11 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: SF Bay area hackfest Message-ID: <20040323195009.T55727@pooker.samsco.home> In-Reply-To: <Pine.BSF.4.21.0403231610210.49185-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0403231610210.49185-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > What else? Is there any platform specific work to be done, outside of the > > > toolchain? > > TLS is "kernel invisible" (other than what we have already done to make > %gs point where we need it.) ((or the equivalent in other > architectures) > so there is no kernel work.. > > that leaves: > > the compiler > the linker > the assembler > the dynamic linker > The thread scheduler/library > > Off the top of my head, I believe these are all the players. > > The linker and dynamic linker are expected to 'plonk' snippets of > machine dependent code into whereever an access to TLS is being made, > depending on whether the access is to the same statically linked module > or another module, loaded at run time, or the 'main' module. > The "wheres" for these 'runtime code-insertions' are marked by the > toolchain. > > The thread scheduler/library is expected to create new TLS segments > whenever a new thread is created, and the linker is expected to request > the thread library to add a new TLS segment to each exisiting thread > whenever a new module is linked in that specifies TLS. The scheduler > keeps pointers correct so that at any moment the correct TLS data is > referenced when needed. As mentionned above the dynamic linker and the > thread library have to co-operate about this. > > The compiler and assembler are expected to generate appropriate tokens > and table entries for the run-time items to do the above when they need > to. This should all be in place for Linux. This sounds fine. Feel free to expand the task list with more detail like this. > > There are optimisations that can be made.. > for example lazy segment creation.. > > It is permissable to only allocate a TLS segment for a particular > module, for a particular thread when that thread first tries to access > said module's TLS data. > that requires 'booby-trapping' all the relocation points but slows down > the thread that have the segment allocated.. but you can sometimes gain > this back by reduced data spread and cache effects. > Let's get basic functionality woring on x86 and amd64 before we start diverging into optimization strategies. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040323195009.T55727>