Re: SF Bay area hackfest

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.

> 
> >  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.