Implementing TLS: step 1

[Alexander Kabaev]

On Thu, 19 Jun 2003 13:20:13 -0700
Marcel Moolenaar <marcel at xcllnt.net> wrote:

> Ok,
> 
> Step 1: static TLS in libthr.
> 
> I have gcc33 installed and looked at the access sequences for TLS
> on both i386 and ia64. Then I looked at libthr to see what was
> needed and the first and obvious orbservation is that we need a
> way to figure out if the binary has a TLS template and use it if
> it does. If not, we probably need some minimal glue to have the
> TLS pointer point to something meaningful. Note again, we don't
> have RTLD involved. We're talking staticly linking now.
> 
> What about the following:
> 
> 1. The kernel already iterates over the program headers and can
>    pass the address and size of the TLS template to the process
>    (or RTLD) by means of the auxargs (ie have AT_TLS_ADDR and
>    AT_TLS_SIZE). If no template exists AT_TLS_* will be zero.
>    This prevents coding object file dependencies on thread and
>    allows the RTLD to modify the args even in the event that the
>    program itself does not have TLS, but libraries in the startup
>    set do.

Any reason why existing AT_PHDR is not enough? 

> 2. On thread creation we allocate the TLS space according to the
>    template (or some MD specific placebo) and put a pointer to it
>    in struct thread. For static TLS we don't have a means to
>    lazily allocate the TLS.



> 3. The MD _get_curthread() and _set_curthread() will be adjusted
>    according to the RT spec. if not currently compliant.
> 
> Question:
> 1. What's the best way to expose the auxargs to the thread library?

rtld can export several _magic_ symbols thread library can look for to
get the info it needs. Alternatively, rtld_thread_init interface can be
extended to pass required into to the library in a structure of some
sort. For static binaries, startup code will have to parse AT_PHDR and
store TLS attributes in a global variable or call a function defined by
the thread library. If I remember correctly, libpthread people wanted to
have that function anyway.


> Alternatives?
> 
> -- 
>  Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to
> "freebsd-threads-unsubscribe at freebsd.org"


-- 
Alexander Kabaev