Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jun 2003 14:05:23 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Alexander Kabaev <ak03@gte.com>
Cc:        threads@freebsd.org
Subject:   Re: Implementing TLS: step 1
Message-ID:  <20030619210523.GA1030@dhcp01.pn.xcllnt.net>
In-Reply-To: <20030619164228.6d2e7dd2.ak03@gte.com>
References:  <20030619202013.GA833@dhcp01.pn.xcllnt.net> <20030619164228.6d2e7dd2.ak03@gte.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2003 at 04:42:28PM -0400, Alexander Kabaev wrote:
> > 
> > 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? 

I assume that in the dynamic case the rtld will construct the TLS
for the initial load set. This is what the threads library should
use as the TLS template.
Put differently: if the threads library looks at the object file
itself, it will correctly obtain the TLS template in static binaries,
but will not have the correct template in shared binaries. What is
missing are the TLS templates in the shared libraries in the initial
load set in that case.

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

This is possible and removes the dependency on the kernel for passing
the info in auxargs. The issue with this is that the startup code may
be doing it for nothing (non-threaded binaries), or interfere in getting
the right information to the threads library and thus making it rather
complex.

What about the following:

The startup code provides a weak function (__tls_template() or
something like that) that is also provided (non-weak) by the
rtld. The threads library calls this function to obtain the
TLS of the initial load set (which for static binaries boils
down to looking up PT_TLS)?
The object details are hidden in the startup code and the
difference between static and dynamic is handled by binding.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030619210523.GA1030>