On Tue, Jun 22, 2010 at 12:26 PM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: >> vfork -> >> vfork syscall (pt-vfork.S) >> >> This has not changed in 2.11.1. > > I just assumed that a change must have occurred because of the behavior > of pex_unix_exec_child in libiberty/pex-unix.c. I didn't investigate > history. Thank you, I don't expect anything has changed, but even if it hasn't there is still a bug in glibc. > Yes. Actually, pex_unix_exec_child may call dup2 and close as well. > In my gdb build, the parent's return address in the frame is clobbered > resulting in pex_child_error being called by the parent. Technically POSIX says it can't call dup2/close, but under Linux the vfork implementation duplicates file descriptors and therefore dup2/close are OK to use before execve. The important part is that vfork *must not* create a frame in the parent that the child unwinds. > I looked at the hpux implementation and it doesn't create a frame. > Of course, the vfork syscall then must not clobber the return address, > etc. Yes, the vfork syscall *must not* clobber r2, without a stack we have nowhere to save it. I'm pretty sure the kernel preserves r2 across a vfork. The next step is to verify that :-) Cheers, Carlos. -- 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
