Implementing TLS: step 1

[Julian Elischer]

On Thu, 19 Jun 2003, Marcel Moolenaar wrote:

Note: The following applies to ia32, but similar comments woudl apply to 
other achitectures.

One thing to bear in mind is that if you push libthr support for TLS
to the absolute maximum you will generate code that is not binary
compatible with KSE (when it gets to ia64).

Libthr has the advantage that the register used for identifying the
current thread can be set DIRECTLY at the thread control block, where
libkse will (probably) require a single indirection. (by which I mean
that the register will point to the control structure for the Virtual
CPU that is running (KSE) and that in turn will have a pointer to the
thread that is currently running.  So to keep binray compatibility we
would need to not push the libthr optimisations to the absolute ends
beyond what can be achieved with libkse (unless the loader code relaxer
can be set up to use different relaxations depending on which thread
library is linked in. (there is SOME precedence for this)).

Libc_r can be modified to set the thread pointer register as needed, but
it might slow it down.  (I was just looking at the ia-32 docs..it's not
as bad as I thought to write a segment register so it is feasible to
change the segment register in libc_r purely to supplrt TLS). (in a code
compatible manner.)

One possible optimisation in libkse would be to place a pointer to the
TLS object table in the Virtual CPU structure (KSE mailbox) whenever a
new thread was scheduled on that KSE/VCPU. This would allow teh
generation of code that bypassed the redirection via teh thread
structure, at the expence of the extra MOV in the context switch.

This would bring it closer to the order of optimisation achievable with
1:1, though the code used for relaxation may or may not be the same.
We just need to decide if the cost is worth it..

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

Call me stupid but can you draw a picture of what you mean?
(it's worth a thoudsand words you know :-)

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

I need to go out to the car and get my copy of the TLS proposal....
this supports exec-time linking but does it support run-time (i.e after
exec has begun) linking?

> 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?
> 
> 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"
>