Carlos, > I have constructed a vfork test case which shows some of the problems > I have using vfork reliably. This fails every time on my PA8700 system > running 2.6.32-rc6. It appears as though r28 (ret0) in the parent is > being corrupted. It seems the vfork implementation has changed in 2.11.1 from using clone to the vfork syscall. I tried to build gdb head today, but it dies at startup due to a problem with vfork. This is potentially also an issue with gcc as it uses the same libiberty code. I filed a sourceware bug, but closed it when I realized that this is a glibc/kernel bug: http://sourceware.org/bugzilla/show_bug.cgi?id=11730 After spending some time looking at this, I realized that __vfork is broken. It should not allocate a frame as the child may clobber the parent's frame when it does a call, etc. A frame should only be allocated and popped around the call to the syscall error handler. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
