Jeff Dike wrote: > It'll be easier to let the userspace child escape - invent an > annotation for "don't follow this clone".
Thanks for the tip. I was getting stuck trying to figure out the ptrace() shenanigans involved with the stub [skas0 mode] that turns SIGSEGV into SIGUSR1. Valgrind has its own ideas about what should happen with signals, and the ptracing gets complicated. > Longer-term, following this clone and allowing full-system analysis > would require some thought. The first problem, of course, is that > about the first the stub does in the new process is unmap everything > but itself, including valgrind. The very first thing that the skas0 stub does is field SIGSEGV because the page which contains the entry point of the PT_INTERP of /sbin/init is not present. The signal handler in the stub forwards this SIGSGEV to uml as SIGUSR1, and the ptrace()ing code inside uml "understands" what the child is doing. Not so when valgrind (or any other virtualization) is involved. Perhaps valgrind could recognize the skas0 stub (SIGSEGV.sa_handler >= 0xbffe0000, etc.) and adapt, or perhaps both valgrind and uml should cooperate here. I'm still puzzling over this one. -- John Reiser, [EMAIL PROTECTED] ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
