|
From: Tom H. <th...@cy...> - 2003-11-14 16:51:48
|
In message <106...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> > I posted a message a while back explaining that I'm not convinced it
> > is possible with the current threading model - I have tried.
>
> Actually, there seem to be two distinct issues here. There's NPTL and
> there's TLS. Are you saying we can't implement TLS without doing all
> the other NPTL stuff?
I can't even get TLS going properly...
I have a version of valgrind that can handle the GDT references
and maintain a mirror of the kernel's thread area table. It doesn't
currently handle set_thread_area and get_thread_area properly but
that would be easy to do.
In fact it will run single threaded programs under NPTL without any
problems as far as I can see.
The problem that I encountered is knowing how to clone the TLS data
when a new thread is started. The TLS data for the first thread is
initialised by ld.so before valgrind gets control so I just use the
get_thread_area system call to ask the kernel where it is.
When a new thread is started the NPTL libpthread creates a new
thread descriptor which seems to include a new copy of the TLS data
from what I could see. It then passes the pointer to that new block
to the clone call and clone sets up the kernel's thread area pointer
for the new thread.
As valgrind has it's own libpthread we would have to work out how
setup the thread area for the new thread, which seems to be very
complicated as the GDT entry set in the kernel seems to point at a
thread descriptor structure which in turns points at the TLS data
and so on.
The other bits of NPTL shouldn't be a problem should they? It just
means implementing things like the futex system call.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|