Date: Tue, 23 Mar 2004 16:47:47 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: SF Bay area hackfest Message-ID: <Pine.BSF.4.21.0403231646170.49185-100000@InterJet.elischer.org> In-Reply-To: <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: > > > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > On Tue, 23 Mar 2004, Scott Long wrote: > > > > > On Tue, 23 Mar 2004, Julian Elischer wrote: > > > > > > > > With new binutils we should (*) be able, with minimal more work be able > > > > to generate statically linked binaries using TLS. (*) the loader needs > > > > to set some values into symbols and the thread scheduler needs code to > > > > allocate a segment of 'M' bytes every time it rceates a new thread and > > > > set a pointer to it.. (it already allocates some info but it needs to > > > > allocate 'M' bytes more) where 'M' is the statically detirmined TLS > > > > size. > > > > > > > > The next step would be to add code to the dynamic linker to be able to > > > > allocate TLS segments to modules as it loads them. The TLS spec pretty > > > > much outlines what needs to be done.. > > > > > > > > We NEED to do this.. it is not a "may be nice" item. > > > > TLS is becoming standard on many platforms and more and more software > > > > is ASSUMING it is present. (e.g. nvidia drivers). > > > > > > > > > > So what david is asking for (and what I've asked for in the past) is a > > > list of tasks that need to be done, and and who is going to be responsible > > > for each one. This is a very reasonable request, and is one that I'm > > > > For the KSE bits, we've already said a few times that we're > > ready to go but are waiting for a toolchain upgrade that > > supports TLS. > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > others add to it. If we can't get through this step, then there is > > > absolutely no way that we can expect to get this done for 5.3. And for > > > the record, I would really, really like to see this done for 5.3. > > > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > > > > Task Owner > > > > > > Import new GCC Alexander Kavaev > > > Import new binutils ??? > > > Modify loader (image activator?) > > > to understand TLS ??? > > > Modify KSE to understand TLS ??? > > > > Yes, I'm sure I and/or David can support this. > > > > > Modify THR to understand TLS ??? > > > Modify C_R to understand TLS ??? > > > > Death to C_R, death to C_R, ... > > I don't think we will support it. I might add that after doing the work for M:N and N:N the code for 1:N may just "fall out" in which case we might look at doing it.. > > > > > > Modify dynamic linker for TLS ??? > > > > > > 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. > > 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. > > > _______________________________________________ > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0403231646170.49185-100000>