On Tue, Jun 22, 2010 at 2:44 PM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: >> > 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 :-) > > Actually, it's ok to save it in the __fork caller's frame at the standard > location. r2 is always saved there by the callee. The argument slots for > r26 thru r23 and the PIC register slot also can be used. I disagree with you. What about this scenario: * Parent call vfork, saves rp in -20(%sp) (parents frame) * Parent suspends upon entry to vfork syscall * Child returns from vfork syscall * Child restores rp from -20(%sp) (parents frame) * Child calls close which saves rp in -20(%sp) (parents frame) * Child calls execve * Parent resumes, restores rp from -20(%sp) and incorrectly returns to just after the call to close. At this point if the parent restores rp from the parents frame it will get the rp the child's call to close saved. The only way to get around this is to *ensure* the kernel saves/restores r2 across the syscall. I see no other way around it. 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
