|
From: Jeremy F. <je...@go...> - 2003-11-14 17:04:08
|
On Fri, 2003-11-14 at 08:51, Tom Hughes wrote: > 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. Urk. I've never really looked at x86 segmentation, let alone how TLS uses it. I'm working on changes to let us get control before ld-linux.so starts. Would that help here? Actually, definitely, yes, because we can always set things up to tell the app that there's no TLS here, nope, go about your business. Another thought: with the new syscalls stuff, every app has its own cloned thread. Could we use those to hang kernel TLS state off in some way? > The other bits of NPTL shouldn't be a problem should they? It just > means implementing things like the futex system call. Well, more to the point, the other bits of NPTL don't have any app-visible API or ABI changes, so we can handle them in our libpthread. We don't need to emulate futex or clone unless someone wants to use them directly. J |