uml: pthreads instead of manual clone()?

Hi Jeff,

is there (still) any reason to use explicit clone() instead of pthreads to spawn UML kernel threads?

While playing with a patch to finally move os_nsecs to proper CLOCK_MONOTONIC, I noticed some subtle side-effect: We need to link against librt for clock_gettime, but that indirectly drags in libpthread. Now gdb gets unhappy when you try to debug the UML kernel. It assumes that pthreads are used, but fails to find their IDs and terminates the session. So the obvious approach appears to be converting kernel threads to pthreads - if there aren't any know pitfalls.

Jan

I think you should better manually copy the clock_gettime syscall stub or function (hoping it's simple enough). Basically, we don't want glibc to do anything by his own free will, like doing TLS setup (pthread could do that), allocating memory from the heap on its own (we only allow it very early, and we try to make it still safe - see the malloc replacement stuff we do through linker and __real_malloc/_whatever_I_dont_recall_malloc). We got a bug once we called getpid() just to get a ptrace notification, but glibc cached the getpid() result: we have our own getpid() syscall stub (at some point I was writing actual UML code, and I wrote some TLS code myself
- not sure whether it's the current implementation or it was rewritten).

Then, maybe, it can be made to work, even if I really wonder about the TLS setup stuff - we need to allow the guest userspace programs to do basically any [gs]et_thread_area() calls. But it's really untrivial IMHO.

Paolo Giarrusso