|
From: Jeremy F. <je...@go...> - 2003-11-19 04:28:52
|
OK, I've had even more of a look into what's happening here. The quick
answer is that is can probably be done without too much nastiness,
though our libpthread will need to know some of glibc's secret
knowledge.
The key thing is that %gs points to a thing called tcbhead_t, which
contains pointers to the rest of the thread-specific data structures.
pthread_create doesn't really do much with this except init it;
___tls_get_addr does all the hard work of on-demand copying, which we
don't care about.
Aside from the shape of tcbhead_t (which is simple), libpthread doesn't
need to know much about how it works - it ends up calling _dl_* internal
functions to manipulate it, and to find out other info it needs to know
(like how big the static per-thread info is, which it needs to build
into the thread stack).
Our libpthread can call those same functions, and thereby do the same
thing.
For reference, they appear to be:
_dl_get_tls_static_info(size_t *size, size_t *alignment)
Get the size and alignment of the per-thread variable space we
need to stick on the stack under tcbhead_t.
_dl_allocate_tls_init(void *mem)
(Re)Initialize the TLS info at mem. mem points to the
tcbhead_t.
_dl_allocate_tls(void *mem)
Do the initial initialization of the TCB (ie, allocate the DTV).
_dl_deallocate_tls(void *mem, bool free_tcb)
Deallocate memory.
tcbhead_t is:
typedef struct
{
void *tcb; /* Pointer to the TCB. Not necessary the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
} tcbhead_t;
We don't care about dtv_t, since the dynamic linker will do all the work
to maintain it.
The other part is implementing the TLS "kernel" support, which is easy.
So in all, this only looks like a few day's work (maybe less).
J
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:40:55
|
On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote: > OK, I've had even more of a look into what's happening here. The quick > answer is that is can probably be done without too much nastiness, > though our libpthread will need to know some of glibc's secret > knowledge. We've mentioned before the idea of dropping Valgrind's libpthread.so, and just doing some low-level clone() interception... would that get around any/all this NPTL/TLS nastiness? That option does have some other downsides, though, particularly it makes it harder to tell tools when interesting pthread events (eg. mutex_lock) occur. N |
|
From: Tom H. <th...@cy...> - 2003-11-20 10:20:00
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote:
>
>> OK, I've had even more of a look into what's happening here. The quick
>> answer is that is can probably be done without too much nastiness,
>> though our libpthread will need to know some of glibc's secret
>> knowledge.
>
> We've mentioned before the idea of dropping Valgrind's libpthread.so, and
> just doing some low-level clone() interception... would that get around
> any/all this NPTL/TLS nastiness?
It should do, yes. We would just need to track the calls being made
to set_pthread_area and clone with the TLS option.
I'm working on trying to get things going with those functions Jeremy
found anyway...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-11-20 17:33:48
|
On Thu, 2003-11-20 at 01:40, Nicholas Nethercote wrote: > We've mentioned before the idea of dropping Valgrind's libpthread.so, and > just doing some low-level clone() interception... would that get around > any/all this NPTL/TLS nastiness? > > That option does have some other downsides, though, particularly it makes > it harder to tell tools when interesting pthread events (eg. mutex_lock) > occur. Yes it would solve the TLS problem, but you'd lose all the other benefits of having our own libpthread. I don't think its a good trade-off. J |