Re: SF Bay area hackfest

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