On Sun, Apr 18, 2010 at 19:50, Jan Kiszka <jan.kis...@web.de> wrote: > 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.
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 ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
