> 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. > Could you please elaborate on the change that you believe occurred in 2.11.= > 1? > > > 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=3D11730 > > > > After spending some time looking at this, I realized that __vfork > > is broken. =A0It should not allocate a frame as the child may clobber > > the parent's frame when it does a call, etc. =A0A frame should only > > be allocated and popped around the call to the syscall error handler. > > Oh dear, yes I see. After the child returns from vfork, it calls exec, > clobbering the vfork frame that the parent must still unwind from. Is > that what you mean? 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. 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. 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
