Re: SF Bay area hackfest

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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>